Page 1 of 1
Property to prevent evaluation
Posted: Thu Oct 15, 2015 5:36 pm
by dunbarx
This came up on the use-list.
The OP wanted to distinguish between "0" and "0."
LC evaluates both strings as equal, since it is trying to be helpful, evaluating these on the fly based on their context. But the issue is whether there should be a property (stringEval?) which turns off this "feature", and keeps strings exactly as, er, strings.
Code: Select all
on mouseUp
put "0" into temp
put "0." into foo
answer temp = foo --"true"
set the stringEval to "true" --default is "false"
answer temp = foo -- "false"
end mouseUp
Workarounds abound. Comparing the length of each string, or whether one string contains ".", etc.
Anyone think this is a useful enhancement?
Craig Newman
Re: Property to prevent evaluation
Posted: Mon Oct 19, 2015 11:11 pm
by [-hh]
Hi Craig.
Of course it is a very good idea to be able to force a string comparison. But also with your proposal there remain some problems. What would you expect to have after that:
Code: Select all
set the stringEval to "true"
set the stringEval to "false"
What is now the state of stringEval?
Is LC allowed to handle in the second line above "false" as false?
Hermann
p.s. Your next post (#3361) is a prime. Be careful with that
Re: Property to prevent evaluation
Posted: Mon Oct 19, 2015 11:35 pm
by FourthWorld
How about:
Code: Select all
on mouseUp
put "0" into temp
put "0." into foo
answer temp = foo --"true"
answer StringEquals(temp,foo) -- "false"
end mouseUp
function StringEquals p1, p2
return (p1&"x" = p2&"x")
end StringEquals
Both an engine solution and a custom function require the user to learn a new token to add to their code, but the latter can be used today without having to wait for the engine team to clear their plates.
Re: Property to prevent evaluation
Posted: Tue Oct 20, 2015 1:05 am
by [-hh]
Very clever solution, impressive by its simplicity, and good for 99% of cases of application.
But are you sure that a (beginner) scripter has always the correct "input format" available?
This becomes a bit subtile now:
Code: Select all
StringEquals( "0+0", "0+empty" ) --> false
StringEquals( (0+0), (0+empty) ) --> true
StringEquals( 0+0 , 0+empty ) --> true
StringEquals("true", true ) --> true
Certainly, all four examples give *false* when read in from a field.
If this is hidden in variables one may need a long time to find such critical issues.
Re: Property to prevent evaluation
Posted: Tue Oct 20, 2015 2:23 am
by dunbarx
Hermann.
So good to have your brain back here.
Richard.
The function cuts through what might be called a case of the barber shaving himself. I suggested to the OP similar kluges, like comparing the length of the two strings. But would it be permitted, if there ever is an engine solution, to set the property to "1" or "2", instead of "true" or "false", so that the barber never has to shave at all?
Hermann.
When I went through 1729, I noticed.
Craig
Re: Property to prevent evaluation
Posted: Tue Oct 20, 2015 2:55 am
by FourthWorld
Maybe even better would be an option to declare data types. When declared, the data would remain in the specified type and avoid all automatic coercion.
Toolbook did that, with one additional - and rather significant - advantage: once they allowed optional data types, it became possible to talk directly to OS API calls from the scripting language.
I realize that's where Builder comes in, but it would be super-cool to have that in LiveCode Script. Tookbook was very good to work with in that way, having to learn just one language for anything we needed.