> > 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