When I was thinking about unquoted literals I was thinking about string literals, something like put one into counter Or put one into two
Numeric literals don’t offend the senses: put 1 into counter In the case of property assignments I could be persuaded either way: that there is a global constant left that means “left” (making it a reserved word), that in the context of certain properties, certain string values are constants and not containers (not as ideal since there is then also going to have to be a warning to the user that their container called “left” is not going to work in the context of the property), that we’re going to have to quote “left” (also not ideal), or that we’re going to allow unquoted string literals in property assignments (but then we are back to the parser/lexer really should error check assignments for some properties so someone doesn’t set the align to tpo unless tpo had previously been used and/or assigned a value, and therefore appears in the symbol table). The last one gets us back to having the parser/lex doing some spellchecking or symbol lookup. Deprecating “features” is often the right thing to do because it cleans up kluges that are no long necessary, and clarity and simplicity and order are restored. Yes, that means that some code will be affected and have to be reworked. It’s either that or n00bs need a separate note in the dictionary for every kluge, the same way that non-native English speakers get to fight through every exception in spelling and punctuation. I sometimes mention the running joke in 4D, “The Tao”, a collection of all the things that are counterintuitive that you have to work around. _______________________________________________ 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
