Versions Compared
Key
- This line was added.
- This line was removed.
- Formatting was changed.
Excerpt | ||
---|---|---|
| ||
We try really hard to make sure every new version of Power Scripts will work with your existing scripts and configurations. However, sometimes in order to bring new features to life we need to break a few eggs. |
We try really hard to make sure every new version of Power Scripts will work with your existing scripts and configurations. However, sometimes in order to bring new features to life we need to break a few eggs.
Version 5.8.0.x
Info |
---|
In order to help mitigate the impact of these changes we have created a script (attached) that is designed to help files that could be impacted. This script does not guarantee that all functional changes will be captured. However, it should greatly assist those users who have a large number of scripts that require checking. See the attachments section at the bottom of this page for a link to the script(s). |
Introduction of Null Constant
Since the concept of a null constant has been introduced in version 5.8.0+, any variables that may have been named ‘null' or ‘nil’ will cause an error since those are now reserved keywords for the language.
Introduction of Integer Type
Beginning with SIL Engine version 5.8.0.x, all numbers are declared integers by default and will return whole numbers upon execution if they are not cast as numbers. If you wish to return decimals, you must implicitly or explicitly cast all numbers in the equation to be of type “number”.
Example 1
In the following example, the equation script will now return “1” because literals such as “3” and “2” are cast as integers.
Code Block |
---|
return 3/2; |
To implicitly cast “3” and “2” as a number, add a decimal point. This script will now return the value of “1.5”.
Code Block |
---|
return 3.0/2.0; |
You can also explicitly cast the values as numbers.
Code Block |
---|
return (number) 3 / (number) 2; |
…and again like this:
Code Block |
---|
number x = 3; number y = 2; return x/y; |
Example 2
In this example, the following equation script will return a whole number: 1.
Code Block |
---|
return 1 - 0.25; |
To implicitly declare 1 as a number, add a decimal placeholder to the equation.
Code Block |
---|
return 1.0 - 0.25; |
…and now to explicitly cast 1 as a number:
Code Block |
---|
return (number) 1 - 0.25; |
Lastly, numbers can be explicitly cast like this:
Code Block |
---|
number x = 1; number y = 0.25; return x - y; |
Error Handling
The introduction of the integer type has also the following consequence:
Code Block |
---|
try { ..... if( ... ) { throw 1; //integer! } if( .... ) { throw 2; //these are integers literals now } } catch integer i { //you need to add this block in order to deal with the above throws } catch number n { //you need to move code from here in the above block! } |
Packages
We added package and the “use“ keyword, please consider “use“ and “package“ keywords as inappropriate for variable names ('package' may be used in the future)
Issue Type and Project fields
are now read-only and will error if you are trying to set them. In previous versions, changing the issue type and project would not error, although they didn’t do anything.
Arrays
When accessing an invalid element in the array for read (in older versions) the array was automatically grown. By invalid element we mean the element arr[i] with i >= size(arr). This was changed in new SIL Engine, reading an invalid array element no more increase the size of the array. Only by setting it the array is increased. Normally this should not have any impact, but some may have used this mechanism to reserve the space in an array, so please be aware that you will now need to do an explicit arr[i] = null; before size is grown, if needed.
Workflow Validators
In version 5.8.0.1 we fixed older bug, changing the way fields in validators are handled. getInput() routine took values from the screen, but accessing the field directly got the same value. To make a difference between the values stored in the issue and the value from the transition screen, we made the following convention:
customfield_xxxxx / fieldName or - to get the value saved inside the issue
getInput(“customfield_xxxxx”) or getInput(“fieldName”) - to get the value from the screen. ( getInput )
hasInput(“customfield_xxxxx”) or hasInput(“fieldName”) - to check if there is a value set on the screen ( hasInput )
We know that there are customers who have already implemented scripts using the wrong version, but we assumed the risk of upsetting them, by knowing that the fix is really needed.
Contents
Table of Contents |
---|
Attachments
Attachments |
---|