This is a follow up article to Checking for an empty String, which was aimed at non typed eScript.
This time around we will look at the pitfalls of string comparison in the ST engine.
I'll assume that you've read the previous article, so i'll jump right into it with this scenario.
[1st Pitfall]
Before we begin, i'd like to highlight the first pitfall. Since we've declared our variables as a String Object, we can no longer do
Even if we've assigned sEmpty and sEmpty2 the same values, and we trace out the values of both variables, it will look the same, but it will return false.
The reason is sEmpty and sEmpty2 are both pointers to two different objects in memory, so what we are really asking the engine is, are these two objects the same object? Even if they are identical, the answer is No.
[2nd Pitfall]
The correct method of evaluating strings is to use the valueOf or
toString method.
Siebel provides an example of how to perform this in Siebel Support [ID:
757503.1]
Unfortunately, the above examples will always return true regardless of the value of the string.
If you have strong typing enabled in your Tools, type sEmpty followed by the dot and you will get a drop down list of available methods for this object, select the valueOf option, and add the () after it.
This is very important, as explained below
valueOf This returns a pointer to the function
valueOf() This executes the function and returns the value.
So when we use the following expression
We are asking the engine, does the function of o1Test.valueOf match the function of o2Test.valueOf? Yes, both functions are the same.
If we used the parenthesis
We are asking does the value of o1Test match the value of o2Test, which is the correct way of executing this. Siebel should default its intellisense to include this parenthesis for function calls.
[Checking if a ST String is empty]
[ST Method 1]
[Method 2]
[ST Method 3]
[ST Method 4]
If you strong type your string variables, the compiler will give a warning if you try to assign or initialise the number 0 to a string, so you avoid the pitfalls of method 1 & 4 of the T engine.
So what happens if we dynamically assign the string object a number as in the example below?
In this scenario, Siebel will not catch it during compile, but it will implicitly convert the number to a string during runtime.
The problem still remains when sEmpty is set to null, because .length, .valueOf will not work on null objects, the workaround for this is similiar to the T Engine. Either initialise your variables or check that the object is not null first.
[Conclusion]
If we strong type our string we avoid the problem when a Zero is assigned to a string, either Tools will prevent you from compiling the code, or the engine will convert it to a string for you anyway.
But the question on everyone's mind at this point should be, is it recommended to strong type Strings and other primitive variables in the Siebel ST engine?
This article from Ponderproserve provides a good answer on this.
http://www.ponderproserve.com/SiebelScriptEngineBenchMark.html
In a nutshell, strong typing primitives will slow down scripting in your application and is not recommended until Siebel fixes this problem.
This time around we will look at the pitfalls of string comparison in the ST engine.
I'll assume that you've read the previous article, so i'll jump right into it with this scenario.
//declare vars
var iZero = 0;
var sEmpty:String = "";
var sEmpty2:String = "";
[1st Pitfall]
Before we begin, i'd like to highlight the first pitfall. Since we've declared our variables as a String Object, we can no longer do
if (sEmpty == sEmpty2)
//returns FALSE
Even if we've assigned sEmpty and sEmpty2 the same values, and we trace out the values of both variables, it will look the same, but it will return false.
The reason is sEmpty and sEmpty2 are both pointers to two different objects in memory, so what we are really asking the engine is, are these two objects the same object? Even if they are identical, the answer is No.
[2nd Pitfall]
The correct method of evaluating strings is to use the valueOf or
toString method.
Siebel provides an example of how to perform this in Siebel Support [ID:
757503.1]
if (o1Test.valueOf == o2Test.valueOf)
//OR
if (o1Test.toString == o2Test.toString)
Unfortunately, the above examples will always return true regardless of the value of the string.
If you have strong typing enabled in your Tools, type sEmpty followed by the dot and you will get a drop down list of available methods for this object, select the valueOf option, and add the () after it.
This is very important, as explained below
valueOf This returns a pointer to the function
valueOf() This executes the function and returns the value.
So when we use the following expression
if (o1Test.valueOf == o2Test.valueOf)
We are asking the engine, does the function of o1Test.valueOf match the function of o2Test.valueOf? Yes, both functions are the same.
If we used the parenthesis
if (o1Test.valueOf() == o2Test.valueOf())
We are asking does the value of o1Test match the value of o2Test, which is the correct way of executing this. Siebel should default its intellisense to include this parenthesis for function calls.
[Checking if a ST String is empty]
[ST Method 1]
if (sEmpty.valueOf()=="")
//TRUE
[Method 2]
if (sEmpty.length==0)
//TRUE
[ST Method 3]
if (sEmpty.valueOf())
//TRUE
[ST Method 4]
if (sEmpty.valueOf()==="")
//TRUE
If you strong type your string variables, the compiler will give a warning if you try to assign or initialise the number 0 to a string, so you avoid the pitfalls of method 1 & 4 of the T engine.
So what happens if we dynamically assign the string object a number as in the example below?
sEmpty = iZero;//dynamically assign number to ST String
In this scenario, Siebel will not catch it during compile, but it will implicitly convert the number to a string during runtime.
The problem still remains when sEmpty is set to null, because .length, .valueOf will not work on null objects, the workaround for this is similiar to the T Engine. Either initialise your variables or check that the object is not null first.
[Conclusion]
If we strong type our string we avoid the problem when a Zero is assigned to a string, either Tools will prevent you from compiling the code, or the engine will convert it to a string for you anyway.
But the question on everyone's mind at this point should be, is it recommended to strong type Strings and other primitive variables in the Siebel ST engine?
This article from Ponderproserve provides a good answer on this.
http://www.ponderproserve.com/SiebelScriptEngineBenchMark.html
In a nutshell, strong typing primitives will slow down scripting in your application and is not recommended until Siebel fixes this problem.
