> Smalltalk evaluates and and or operators the same way. Most evaluation
> is done from left to right with only a few different priorities.
Yes, and this is consistant behaviour for Smalltalk, as Smalltalk uses
left to right evaluation even for +, * arithmetic.
Smalltalk only prioritizes between
unary selectors which bind the tightest
binary selectors which are next (so a negated + b is (a negated) + b
keyword selectors which are last
object jump: x + y * z towards: fred location
is interpreted as
object jump: ((x + y) * z) towards: (fred location)
I wouldn't say it is wrong the way ruby does it, but not exactly
intuitive either. Choosing to follow english language rather than
widespread convention *and* similiar constructs in ruby itself (&&,
>>, +, *, ...) may seem a bit ... anti POLS.
A perl programmer would be very surprised if AND, OR, && and || worked
any other way. Probably the most common perl idiom here is:
"some long complicated expression" or die
I feel this is a true case of POLS violation, not one of those "I
don't know shit, and I was surprised" examples. I do know about
operator precedence in ruby in general, and was surprised by this
special case. Never ran into it myself though, probably because of
luck or spurious parentheses.
It's often pointed out that it's impossible to minimize EVERYONE's surprise.
It's not a major deal. It certainly can't be changed in 1.8 without
breaking code. Who feels this is worth changing in 1.9?
On 8/30/06, Jürgen Strobel <firstname.lastname@example.org> wrote:
On Tue, Aug 29, 2006 at 08:55:09AM +0900, Michael W. Ryder wrote:
My blog on Ruby