On 7/14/06, Alex Tweedly <[EMAIL PROTECTED]> wrote:
If there was any context where either could appear, there would be an ambiguity - but there isn't.
So assuming the new syntax was adopted: x = 4 -- I assume x is 4 (x = 5) -- I assume x is now 5 set the customBoolenProp of stack myStack to (x = 4) -- it would put false set the customNumericProp of stack myStack to (x = 6) -- it would put 6 into x and into the customProp If I got use to 'x = 4' being a valid var assignment, then I would assume that as with other Rev statements, placing it in brackets would make it just as valid but calculated earlier, to have it suddenly not have it work as expected is some cases (although I really can't see myself using the above) would cause confusion. Although you are probably right in that it may not break current code, I see that it could create confusion, or at least have a bunch of 'extra' rules associated with it. I also assume that this is why languages that use 'x = 6' use 'x == 6', because determining the meaning by context seems a little roundabout when you can use syntax. My 2 clams worth _______________________________________________ use-revolution mailing list [email protected] Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-revolution
