On 21/01/2015 15:53, Geoff Canyon wrote:
the obvious drawback of the way it is now is that both outcomes have
> to be evaluated, where in an if statement, obviously, only one of them is.
True, but (coding style preference) I tend to use it pretty much only for
constants. If there's a complex expression in there, I prefer to split it out
onto lines where there's more whitespace around the expressions to help
future-me comprehend the code!
Of course there's a speed penalty to using a function in this way (though
there wouldn't be if it was built in*) - generally I'm using it to make the
code more readable, to avoid the eye+mind tripping over a big expression
that's only doing a simple thing, when it will be more comprehensible as e.g.
set the spotcolour to ifte(status="good","green","red")
To my mind, that makes it more obvious how limited this issue is - I can
quickly see that this is just about setting red or green according to the
status - whereas the five line
if status = "good" then
set the spotcolour to "green"
else
set the spotcolour to "red"
end if
forces me to read it more carefully to check whether there are other actions
being taken depending on the condition, whether it's the same property being
set in both, etc.
Ben
*Sorry, I've only just realised as I was about to press send that the point
you were making was that if it was built-in, then it also wouldn't need to
evaluate both outcomes. Good point - though I'd personally still tend to
restrict the use to constants or very simple expressions.
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
