|
1 | 1 | # Breaking changes |
2 | 2 |
|
3 | | -## Standalone Building |
4 | | - |
5 | | -The standalone builder has always needed to close the stacks it builds |
6 | | -for reasons pretty deeply ingrained in the code. However this causes a |
7 | | -few problems, for example: |
8 | | - |
9 | | -* values in script locals become empty |
10 | | -* behaviors are broken when the parent script is on / in a stack which closes |
11 | | - |
12 | | -As an attempt to improve this situation, the code that locks messages |
13 | | -when closing and opening stacks for standalone builds has been removed. |
14 | | -This means that where previously mainstacks would not receive any of the |
15 | | -`(pre)open*` and `close*` messages (e.g. `preOpenStack`, `openStack`, |
16 | | -`openCard`, `closeStack` etc) during standalone build, they now do. |
17 | | - |
18 | | -If this causes problems for your stack, you can exit from the handler if |
19 | | -standalone building is in progress: |
20 | | - |
21 | | - on closeStack |
22 | | - if the environment is "development" and \ |
23 | | - there is a stack "revStandaloneProgress" and \ |
24 | | - the mode of stack "revStandaloneProgress" > 0 then |
25 | | - exit closeStack |
26 | | - end if |
27 | | - end closeStack |
28 | | - |
29 | | -## LiveCode Builder |
30 | | - |
31 | | -### Exponentiation operator precedence |
32 | | -Prior to this release, exponentiation had lower precedence that unary |
33 | | -minus. In order to write code that operates as expected in both this |
34 | | -release and previous releases, please use parentheses where appropriate. |
35 | | - |
36 | | -Using lc-compile tool in LiveCode 9: |
37 | | - |
38 | | - -1^2 = -1 |
39 | | - |
40 | | -Using lc-compile tool in LiveCode 8: |
41 | | - |
42 | | - -1^2 = 1 |
| 3 | +## Boolean constants |
| 4 | + |
| 5 | +In this release, boolean constants `true` and `false` have been changed so that |
| 6 | +they resolve to values of boolean type (rather than string). This will affect |
| 7 | +any uses of the `is strictly` operator on such values, i.e. previously the following |
| 8 | +were true: |
| 9 | + |
| 10 | + true is strictly a string |
| 11 | + false is strictly a string |
| 12 | + |
| 13 | +Now, they are both false, and the following are true: |
| 14 | + |
| 15 | + true is strictly a boolean |
| 16 | + false is strictly a boolean |
| 17 | + |
| 18 | +Boolean constants passed as elements of arrays to LCB handlers will not require |
| 19 | +conversion to boolean values in LCB - in fact any attempt to do so assuming they |
| 20 | +are strings will cause an error. Any array elements which are intended to be |
| 21 | +booleans in LCB should be checked for their type before conversion. For example, |
| 22 | +any of the following could be done by an LCB library user: |
| 23 | + |
| 24 | + put true into tArray["enabled"] |
| 25 | + put "true" into tArray["enabled"] |
| 26 | + put (tVar is not "enabled") into tArray["enabled"] |
| 27 | + |
| 28 | +An LCB handler to which `tArray` is passed should do the following: |
| 29 | + |
| 30 | + variable tEnabled as Boolean |
| 31 | + if tArray["enabled"] is a boolean then |
| 32 | + put tAction["enabled"] into tEnabled |
| 33 | + else |
| 34 | + put tAction["enabled"] parsed as boolean into tEnabled |
| 35 | + end if |
| 36 | + |
| 37 | +## Infinity constant |
| 38 | + |
| 39 | +The constant `infinity` has been added to the language in this release. As a |
| 40 | +result, the unquoted literal `infinity` is now reserved. Any existing uses |
| 41 | +of it should be quoted, as otherwise it will resolve to the floating point |
| 42 | +value representing infinity, rather than the string "infinity". |
0 commit comments