Property to prevent evaluation

[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

[[-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

[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.

[[-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.

[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

[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.