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

On Wed, Nov 06, 2002 at 12:15:38AM +0900, Austin Ziegler wrote:
> On Tue, 5 Nov 2002 20:18:47 +0900, Brian Candler wrote:
> > 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.
> 
> Actually, it's arguable C++ *the language* (like C) defines a=a+b
> and a+=b to have identical behaviour.

I disagree. For integers/pointers yes, but for objects the language defines
+ and += to be two independent methods. If you define + and don't define +=,
then you simply don't get +=. If you do choose to define +=, then:

(a) there is no requirement for it to behave like '+' at all, although it
    would be perverse if you chose to make it completely different; but
    more importantly,
(b) the operations of
      a += b       "add 'b' to myself" (mutating)
      a = a + b    "calculate the value myself 'add' 'b', put the answer in
                    a new object, and assign that to 'a'"
    are in any case not the same, even if 'add' is the same operation.

But I have to admit that it is many years since I've written any C++. I gave
up in disgust, basically because a slip of a '&' or '*' could end up with a
program which was completely syntactically valid according to the compiler,
but just segfaulted when you ran it :-(

> I read Gavin's statement to be
> s statement about the native language support. += is overridable in
> C++ for performance reasons -- and for no other reason.
...
> The only place where I really disagree with Gavin's statement is
> that it's not 100% identical behaviour.

So, is that like someone being not 100% pregnant? :-)

> Because += is there for
> performance reasons, and we know that the object is itself mutable,
> it doesn't need to return a reference to a new object in C++, but it
> will in Ruby. The *effect* is the same, but the behaviours aren't.

Then I think I have missed some subtle difference between "effect" and
"behaviour" here...

I still don't think it's all down to performance. There are perfectly valid
cases where you really *need* to do

      a << "foo"
instead of
      a = a + "foo"

say when 'a' references a node in a tree or graph structure. If you used the
second case, you would have to also update all references which pointed to
the old 'a' to point to the new one.

Regards,

Brian.