On Fri, Oct 16, 2015 at 7:42 AM, Mark Waddingham <m...@livecode.com> wrote:
> I pondered 'is exactly' for the 'is really' semantics... I'm wondering > whether 'is strictly' is perhaps most appropriate I've come to this topic late but I'm wondering if all these language additions aren't making it all the more complex. What about an alternative approach of using a property to turn 'strictness' on or off, in much the same way as caseSensitive is used. Although instead of true or false the 'strictCompare' property may have to be tri-level and obviously default back to 0 (highest level of coercion) at the end of a handler. The benefit is that you don't have to remember all those subtle syntax variations. set the strictCompare to 0 --current default level of coercion put 1 = "1.0" --true put 1 = 1.0 --true put 0.1 = "0.1" --true put "1.0" is a number --true put "0.1" is a number --true put "1.0" is an integer --true put "0.1" is an integer --false put "THIS" = "this" --true set the strictCompare to 1 --strings are strings, numbers are numbers, but values are coerced put 1 = "1.0" --false - number vs string put 1 = 1.0 --true - value is the same put 0.1 = "0.1" --false number vs string put "1.0" is a number --false it's a string put "0.1" is a number --false it's a string put "1.0" is an integer --false it's a string put "0.1" is an integer --false it's a string put "THIS" = "this" --true * --basic value is the same set the strictCompare to 2 --by-passing all type-coercion put 1 = "1.0" --false - number vs string put 1 = 1.0 --false - not exactly the same put 0.1 = "0.1" --false number vs string put "1.0" is a number --false put "0.1" is a number --false put "1.0" is an integer --false put "0.1" is an integer --false put "THIS" = "this" --false -exact value not the same * * strictCompare 1 would leave caseSensitive set at false so basic string values can be compared as is, but at strictCompare 2 the caseSensitive would be set to true so all comparisons of exactness return a logical result. Some edge cases: set the strictCompare to 0 put 0.1 = .1 --true -value is the same put .1 is a number --true put 1. is a number --true put 1.0 is an integer --true put 0.1 is an integer --false put .1 is a number --true put 1. is an integer --true set the strictCompare to 1 --without a preceding or trailing 0 . is coerced to a period ** put 0.1 = .1 --false - number vs string put .1 is a number --false --it's a string put 1. is a number --false --it's a string put 1.0 is an integer --true as it's coerced to 1, 1 = 1.0 put 0.1 is an integer --false put .1 is a number --false --it's a string put 1. is an integer --false --it's a string set the strictCompare to 2 --without a preceding or trailing 0 . is coerced to a period ** put 0.1 = .1 --false - number vs string put .1 is a number --false --it's a string put 1. is a number --false --it's a string put 1.0 is an integer --false, it's a number with a fractional part, 1 <> 1.0 put 0.1 is an integer --false put .1 is a number --false, it's a string. put 1. is an integer --false, it's a string. ** The reason in my mind that . should be considered a period in 'strict' mode (2 or 1) is that in the vast majority of text that might be parsed, if it's come in (via a spreadsheet or some other means) as a number it will have preceding or trailing zeros if there is a decimal point and clearly be a number; otherwise it would be as part of a chunk of text: 1. A 3 item list 2. Now there are 2. 3. The last item. LC already provides a way for us to easily extract the value of these numbers out of the chunk of text, but only by strictCompare set to 0 or 1 would it be possible to easily determine that these numbers are in fact just strings in amongst words as part of lines of strings. There is no "is a string" function - and I'm not suggesting there should be - but just because 'is a number' returns false can be used to assume you have a string, it will also give you false positives. So in the list above 'word 3 of line 1 is a number' should return false if strictCompare is set to 2 or 1 because strictly the whole lot is stored as a string so the 3 in 'A 3 item list' even without a preceding or trailing . is still a string. _______________________________________________ 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
