> > f = Foo.new()
> > i = f.a = 42 # i == 42
> > i = f.b = 42 # i == 42 (now it's 42, but should be 28)
>
> What is in debate is "should be 28". I expect:
>
> i = f.b = 42
That precludes a module from altering the return value though. If
you're doing:
i = f.b = 42
and the Foo authors intentionally changed the return value, as the
author of Foo, I would be ticked that the return value that I am using
isn't being honored and is instead being overridden by the parser.
> to be the same as:
>
> f.b = 42
> i = 42
Egads! Really? That breaks from what the OO paradigm provides you
with. Try this on for size. Things used to be this way:
i=(f.b=(42))
But now they're like this:
f.b=(42) && i=(42)
Which is a fundamental shift away from operators as methods and why
I'm kinda up in arms about this philosophical change. In an OO world,
I expect i=(f.b=(42)).
Return values are pushed onto the stack and then popped off by the
subsequent function allowing functions to be nested and their return
values used as arguments. -sc
--
Sean Chittenden