String to Bool casting

Monkey Forums/Monkey Programming/String to Bool casting

Samah

(Posted 2012) [#1]

I would have expected Bool("true") to be true, and Bool("false") to be false, but it seems Monkey assumes any non-empty string is true, and an empty string is false.

Can we get this changed? I had to alter the Diddy particle system to check for ="true" so that you can correctly set an XML attribute to "false".

You could make this backward compatible by casting to False if the string is "" or "false", otherwise True.
[monkeycode]Local cast:Bool = (val And val.ToLower() <> "false")[/monkeycode]

Gerry Quinn

(Posted 2012) [#2]

"I would have expected Bool("true") to be true, and Bool("false") to be false".

I don't think this would be a standard expectation. I would much prefer it left as it is. And what about strings such as "True", "ja", "sure", "probably", "1", etc.?

Also, it would slow string conversions, and probably break existing code for text-wrapping and such.

marksibly

(Posted 2012) [#3]

Hi,

> Can we get this changed?

Nope, I much prefer the behavior of 'non-empty' meaning true and 'empty' meaning false.

It's simple, applies to both strings and arrays, and removes any confusion over what 'true' or 'True' or 'false' or 'False' or '1' or '0' or '1.0' or '0.0' etc get converted to.

golomp

(Posted 2012) [#4]

Sorry Samah but i also think the actual system is ok and improve speed...
But i dont really realize the impact on Diddy and what possibilities it close.
Can you give some details on Diddy consequences ?

Samah

(Posted 2012) [#5]

It doesn't matter, I just changed it to be an ="true" check, as silly as it is. I'm not fighting it.

therevills

(Posted 2012) [#6]

IMO I don't think casting a string to a bool should be allowed in the first, it just doesn't make sense to me.

ziggy

(Posted 2012) [#7]

Also, I hate it when runtime cast operations rely on culture info. Would it still have any sense on a nonenglish language program... ? I do preffer it too as it is now.

Samah

(Posted 2012) [#8]

Then I agree with therevills. If it doesn't make sense to cast an empty string to a numeric value, I don't see how it makes sense to cast to a bool. It only exists for a quick and dirty way to check for empty strings.

Gerry Quinn

(Posted 2012) [#9]

It's a C tradition, I guess. In C an empty string starts with 0 (and no other string does) so the test is very quick and efficient.

Personally I'm okay with it. I don't necessarily expect strings to have implicit casting to bools, but if they do have it, empty->false is what I expect.

And if strings cast to numbers, it should be either to the number in a standard language format, or zero. Strings should not be castable to any number system that doesn't contain zero ;-)

ziggy

(Posted 2012) [#10]

Then I agree with therevills. If it doesn't make sense to cast an empty string to a numeric value, I don't see how it makes sense to cast to a bool.

I see no problem with this. You can convert ANY object to bool and it'll be true if it is not null. It sort of the same logic, If we go this far, it should not be allowed to do:

If myObject Then Whatever()

Wich is something I really like about monkey, instead of being forced to write:

If myObject <> Null Then Whatever

It gets too verbose without making the code any easier to follow.

tiresius

(Posted 2012) [#11]

Dangit ziggy - I have <> Null checks all over my code, now I have to go fix. :)

I agree with empty string being False as it makes sense to me (with a background in a functional language and the concept of Nil / Non-Nil determining conditions).