Ooo. This is one that I can answer. In most computer language syntax, the statement @X = "Y" assigns the value "Y" to variable @X.
In some comptuer languages, the *expression* ( @X == "Y" ) compares @X and "Y" for equality (does @X contain the value Y" ?) and returns a result of true or false. In some of those comptuer languages, the assignment statemet @X = "Y" is also considered an expression, in that it returns the value of @X after the assignment. This is often a useful feature. In some of those languages, a non-zero result is considered the same as boolean TRUE E.g. IF ( 1 ) THEN PRINT "IT'S TRUE!" always prints "IT'S TRUE!" because (1) evaluates to TRUE in that context. So, in that kind of language, the typographicial error of omitting one = from a comparison turns the comparison into an assignment, unexpectedly having the side effect of changing the value of the left-side operand! So: // compare for equality, if the result is true, print "EQUAL" IF ( @X == "Y" ) THEN PRINT "EQUAL" Mistype that to leave out one = symbol: // assign value to x, then if x is non-zero/ non-empty, print "EQUAL" IF (X = "Y" ) THEN PRINT "EQUAL" Whoops! Unexpected results! X is always non-empty, because it is assigned the value "Y"! Also, after this statement, X always contains "Y" Giles suggestion, to reverse the order of the terms, is a good one, because it prevents a typo from compiling without error and accidentally causing an assignment at run-time, and instead generates a compile-time error, pointing out the typo! ~~James _____________________ http://www.turtlezero.com On 10/25/06, Phil Henshaw <[EMAIL PROTECTED]> wrote: > Giles, > > Can you explain what that causes? You say "is prone to accidental > assignment". Sounds like variables erroneously change value when > queried. That's not good. My limited experience is different, that > code has all kinds of unexpected and hidden structure because it was > written by people like me who can't keep a few dozen simple logical > steps straight when interacting with few dozen others written by someone > else (i.e. there's confusion lying all around). Is that also why > variables are accidentally reassigned? Or something different? > > Ok, so then what happens after that? You don't just come to the wrong > answers it seems, but frequently trigger a cascade of mismatching stuff > that sometimes gets 'trapped' and sometimes not? Would you describe it > differently? > > > > > About the only useful discovery I've made along these lines: > > > > Never do this: > > > > if @var == "Value" > > > > Always do this: > > > > if "Value" == @var > > > > the reason is because, if you screw up and only put in one > > equals sign, pretty much every language out there is prone to > > accidental assignment-during-test bugs, but no languages that > > I'm aware of are prone to accidental > > assigning-new-values-to-literals bugs. > > > > For what it's worth... > > > > -- > > Giles Bowkett > > http://www.gilesgoatboy.org ============================================================ FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College lectures, archives, unsubscribe, maps at http://www.friam.org
