codes in if statements are not parsed correctly

[BangL]

example:

if (isNull _bla && {_bla != ""}) then {};

in this example one if-condition is in {}-brackets, which will lead into this condition not beeing checked unless the other one was true. - this is a wonderful and proper way of preventing NPE's without having to make two nested if's, but sadly this is marked as invalid.

[kayler-renslow]

This doesn't make any sense. Aren't these two the same?
if (isNull _bla && {_bla != ""}) then {};
if (isNull _bla && _bla != "") then {};
I also don't know what "NPE" means.

[BangL]

NPE is Null Pointer Exception

the example was not the best actually, a better example would be like:
if (isNil "_bla" && {_bla != ""}) then {};

imagine a case where _bla actually IS nil...

if you would write:
if (isNil "_bla" && _bla != "") then {};
it would crash at _bla != "" because _bla is nil, therefore it cant be parsed.
...arma checks the second statement, even if the first was false already. ( the "&&" cant be true in the end anyways)
so, to work around that problem, you can use code-brackets.
this tells the parser to only check the statement if "needed" (depending on the used logical operators)
and so you would not get an "NPE" at _bla != "" anymore

[BangL]

its like a mini-if in an if. :D

[kayler-renslow]

That's kind of weird that the scripting engine doesn't allow short circuiting (check up until one condition is false). I'll put in the change right now.

This would also make for a nice code inspection... I think I'll make it one.

[kayler-renslow]

this has been fixed for next version

[X39]

the <bool> && <code> syntax is for lazy evaluation

it is still recommended to nest the later &&s in the code block further as the script engine still will parse everything otherwise

reason for this btw. is because the script engine will interpret it like so:

&&

which itself again is an expression -->
false && false && false pretty much just means one thing for the script engine:
&&

where either the LArg or the RArg is the same again

lazy evaluation just is a hacky way to prevent the execution at all

[BangL]

a hacky but valid and working way.
the only important question is: should it be marked as a mistake or not. -
it should not, because its not a mistake. coding taste does not matter here.

2016-07-20 16:34 GMT+02:00 Marco Silipo [email protected]:

the && syntax is for lazy evaluation

it is still recommended to nest the later &&s in the code block further as
the script engine still will parse everything otherwise

reason for this btw. is because the script engine will interpret it like
so:

&&

which itself again is an expression -->
false && false && false pretty much just means one thing for the script
engine:
&&

where either the LArg or the RArg is the same again

lazy evaluation just is a hacky way to prevent the execution at all

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#14 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAhp6CSxzKAQ44QQxVpeSXFiwIseGWFJks5qXjISgaJpZM4JKXeg
.

Bitte senden Sie mir keine Word-, Excel- oder PowerPoint-Anhänge. Siehe
http://www.gnu.org/philosophy/no-word-attachments.de.html
http://www.gnu.org/philosophy/no-word-attachments.de.html

[X39]

was just the explaination for that @BangL

SQF does not knows lazy evaluation due to that
the code block R-/LArg is just adressing that issue ...
main problem remains: SQF itself is too simple in regards of available syntax

[BangL]

i see. thanks for the expl. then :)

offtopic: are you the x39, who made the xms 1 and 2 ? i was planning to contact you anyways.
i would like to re-use sources of your xms1, but i cant find any license info.