From: Brian Candler <B.Candler@...>
Date: 2002-11-06T09:07:38+09:00
Subject: Re: Thoughts on Ruby

On Tue, Nov 05, 2002 at 11:19:06PM +0900, Gavin Sinclair wrote:
> From: "Brian Candler" <B.Candler@pobox.com>
> 
> 
> > On Mon, Nov 04, 2002 at 10:02:12PM +0900, Gavin Sinclair wrote:
> >
> > (an all-encompassing statement if ever I saw one :-)
> >
> > > a += b is always, by definition, in any language, the same
> > *behaviour* as a = a + b.  If you disagree, you are being absurd.
> >
> > By whose definition? Certainly not the language designers and standards
> > bodies. As a counter-example: in C++, if an object has both "+" and "+="
> > methods, the language definition does not require them to have the same
> > behaviour, and therefore in general they don't. QED.
> 
> By C's definition.  The original and the best.  C++ is of course a
> counter-example, but C invented the terminology "+=", not C++.  You can't just
> redefine things and expect your definitions to be accepted elsewhere.

Ah, well if you'd said "in C" rather than "in any language" then I wouldn't
have taken issue with you :-)

The problem doesn't arise in C anyway, because + and += only apply to
numeric types anyway, and in that case they are indistinguishable.

I'm not taking this seriously either by the way :-)

> > Those two examples do not exhibit the same behaviour in the presence of
> > other variables containing references to the same object as the original
> > 'a'. That's not a "run-time hack", that's a difference in semantics: i.e. "I
> > want to create a new object and leave the old one alone", as opposed to "I
> > want to modify the object itself". The difference is important and not just
> > one of efficiency, unless we know for definite that there are no such
> > additional references.
> 
> I'm not sure what you are getting at in the last sentence.  But I'm sure you
> understand my point that implementation should not be the first concern for the
> programmer who merely wants to get things right.

Well, let's say you get object reference "a" by walking a more complex data
structure like a list or a tree. Then if you change the object in-place, the
value you see when you next traverse the tree is also changed; if you apply
the operator and put the result into a brand new object then the change
won't be seen.

But you know this of course, as it's exactly the difference between "+" and
"<<" in Ruby (for String and Array, anyway).

So I still think it ends up boiling down to convention. For someone who
comes from C++ (which surely claims first usage rights on += as an object
method), then a += "foo" is the same as a.operator+=("foo"). That's more
likely to be an instruction to 'a' to modify its state than to do a
calculation and return a result but leave itself unchanged.

It's Ruby which is breaking with convention when it defines a+=b as
a=a.+(b)  -- not that I am arguing this is a bad thing. I just don't think
you can put somebody down as being "absurd" when they say that they expected
it to work the other way, either because they expected the C++ behaviour, or
because they expected a regular "all operators are methods" behaviour.

Cheers,

Brian.