LiveCode Forums.

Has this been discussed before?

I am building a CAD-like drawing program in LC, and as a convenience I made a gadget to allow me to hide graphics if I simply click on them with the optionKey. I want only graphics to hide. So I tested three conditions: In version two the condition "and the mouseControl <> empty" comes third, after the other two, as opposed to second, between the other two, in version one. That version fails with "no target found" if I click on empty card space,

The card object is not a mouseControl, the function returning empty.

I assume this means that each condition is evaluated sequentially, and clicking on empty space throws an error since the test for graphic "fails" before the empty result from the function "fails".

The pecking order matters, even though each condition on its own is identical between the two versions. I do not see a reason for this at all.

Expected behavior?

Craig

Yes, like Python and others LC uses "lazy" evaluation of conditions, where it only evaluates as much as is necessary to determine branching.

One benefit of this is performance; it simply saves time evaluating things that don't make a difference in execution flow.

Another benefit is what you've found in your example: it allows you to order your conditions in ways that might otherwise throw errors even where a later condition is inconsequential.

I think this is expected, and desired, as a result of lazy evaluation.
With boolean AND tests, if condition 1 fails to return true then the whole test is going to fail, so there's no point in even bothering to check the other conditions.
It follows that where maximum efficiency is desired, conditions should be evaluated in order of most generic to most specific likelihood to fail. But chances are this is unnoticeable in most situations.

[Edit, near simulposting, in agreement with Richard]

Lazy evaluation is one thing, and perfect for someone like me. I figured as much, and mentioned that I recall this being discussed a while ago.

But my main point was not that the logic of my string of booleans was not working the way I intended, but that LC threw an error and halted the handler. I get that my gadget has to be carefully constructed. I do not understand the error.

Craig

Ah, so the problem is that an error is thrown by a statement that reduces towhen the mouseControl is empty, it has no reference to an object from which to extract the name?

dunbarx wrote: ↑

Fri Dec 11, 2020 8:57 pm

...my main point was not that the logic of my string of booleans was not working the way I intended, but that LC threw an error and halted the handler. I get that my gadget has to be carefully constructed. I do not understand the error.

Sparkout got it.

Breaking it down to psuedocode:

Works:
- Test 1: Does the control exist?
- Test 2: What is the name of the control?

Throws error:
Test 1: What is the name of the control?
Test 2: Does the control exist?

Something that doesn't exist can have no name (unless it's a cowboy gunslinger <g>).

Aha,

Thanks. That makes sense.

Craig