is evaluation order defined, and evaluation of conditionals
jhj at jhj.com
Mon Jun 25 23:37:59 CDT 2012
Ah, then it must be actualy guaranteed! Thanks!
I'd still try to write it out the long way with "if"s for the sake of the poor reader (probably me later under stress), but thats a matter of personal style I suppose.
On Jun 25, 2012, at 9:25 PM, Mike Bonner wrote:
> Its useful if you have a processor intensive function (say intersect()).
> You can do several bounds checks prior to the intersect, if any of them
> fail the intersect is never done. This was mentioned in the game academy.
> On Mon, Jun 25, 2012 at 10:18 PM, <dunbarx at aol.com> wrote:
>> Fsscinating example. It seems there is in fact an order to the
>> conditionals, at least as constructed your way. The "false" rendered in the
>> left side seems to (un)satisfy the "and", played out in order. Stepping
>> through shows this clearly.
>> Cool. Is this useful?
>> Crig Newman
>> -----Original Message-----
>> From: Jerry Jensen <jhj at jhj.com>
>> To: How to use LiveCode <use-livecode at lists.runrev.com>
>> Sent: Mon, Jun 25, 2012 11:29 pm
>> Subject: Re: is evaluation order defined, and evaluation of conditionals
>> I'm not Richard, but I'm curious too. Here's an example that may point out
>> In a button script, or somewhere . . .
>> on mouseUp
>> local tFoo
>> put func1() and func2() into tFoo
>> end mouseUp
>> function func1
>> return "false"
>> end func1
>> function func2
>> put "func2 was called"
>> return "true"
>> end func2
>> In this example, func2() IS NOT called.
>> If func1 returns "true" instead, func2() IS called.
>> This behavior is guaranteed in the C language, but I don't know about
>> in LiveCode. In C, similarly if "or" is used instead of "and", if the
>> first part
>> evaluates to "true", the second is NOT called. Again, I dunno about
>> Exercise left to the reader (or somebody who knows!)
More information about the use-livecode