"This difference in how syntax is understood actually presents a barrier to programming for modestly trained mathematicians, who would otherwise be expected to excel."
> And are you implying that the author's original solution is more indicative of real programming?
Well, neither is... but yes, overriding == or .equals is somewhat common.
> when accessing the value of "b" for the first check, b is mutated such that the next check will return a different value.
The difference is that you could easily imagine a sane example where x == y != x === y, whereas it's hard to imagine a situation where I would want to override get (or ==) with a method that mutates the requested variable.
> The == vs. === issue is the part that's actually irrelevant, it served as a red herring.
For the claim re: syntax and compatibility with mathematician's expectation, it's exactly the other way around.
FWIW I feel the quoted claim re: syntax claim is interesting, whereas the contents of the article (summarily, "you can override == or .get and cause crazy stuff to happen") is unsurprising and kind of silly to most programmers even moderately experienced with OOP in dynamic languages (for the reasons given in this post and others -- everyone knows about it, it shouldn't take 11 days to figure it out, and in practice no one does purposefully obscure stuff like mutating values when == or .get is called).
"This difference in how syntax is understood actually presents a barrier to programming for modestly trained mathematicians, who would otherwise be expected to excel."
> And are you implying that the author's original solution is more indicative of real programming?
Well, neither is... but yes, overriding == or .equals is somewhat common.
> when accessing the value of "b" for the first check, b is mutated such that the next check will return a different value.
The difference is that you could easily imagine a sane example where x == y != x === y, whereas it's hard to imagine a situation where I would want to override get (or ==) with a method that mutates the requested variable.
> The == vs. === issue is the part that's actually irrelevant, it served as a red herring.
For the claim re: syntax and compatibility with mathematician's expectation, it's exactly the other way around.
FWIW I feel the quoted claim re: syntax claim is interesting, whereas the contents of the article (summarily, "you can override == or .get and cause crazy stuff to happen") is unsurprising and kind of silly to most programmers even moderately experienced with OOP in dynamic languages (for the reasons given in this post and others -- everyone knows about it, it shouldn't take 11 days to figure it out, and in practice no one does purposefully obscure stuff like mutating values when == or .get is called).
edit: grammar