[ruby-talk:15197] Re: Discussion on new Ruby features

Dave wrote:
>  a = "cat"
>  b = a
>  b += "dog"
>
>  a #=> "cat"
>  b #=> "catdog"
>
> the '+' operator creates a new object.
>
> By contrast, '<<' is 'append', so
>
>  a = "cat"
>  b = a
>  b << "dog"
>
>  a #=> "catdog"
>  b #=> "catdog"
>
>
> This might explain some of the confusion people have been showing :)

OK. I see...

If only I had not started discussion after 3 days learning of Ruby!
On the other hand, Rubies syntax and concepts are so nice that one 
can't help thinking to be an expert after only 3 days. :)

But I still think that one can use this idea to achieve 
significant runtime improvement in several cases (assuming a good optimizer).
It is easy to so why: you can eliminate a lot of temporary variables.
Of course, one has to implement the <operator>= functions in such a way
that it alters the object itself and does not create a new object.
For most purposes, this semantics fits quite well.
The problem is, of course, backwards compatibility.
I don't underestimate it: it is a HUGE one.

On the other hand it is more useful to have the different behaviour
of += to change the object itself, instead of being just an alias for 
. = . + .





In order to maintain backwards compatibility, there would also 
be another possibility:
If the += operator would be defined without allocation, but the
call of the operator would create allocate on need.
I.e.
You would define for Strings:

def +=(x)
   self<<x
end

And the parser would map
x=a+b+c to

x+a.dup
x.+=(b)
x.+=(c)

On the other hand
x+=a would map to
x.dup+=a

So we keep the original semantics.

Of course, this would contradict the principle of "least surprise" a bit,
but perhaps it is worth it.

In the sample code

NUM.dowto(0)
   a+=b
end

A good interpreter now could optimize the a+=b by omitting the allocation
(and the compiler CAN omit it since the compiler generates it...)
since it would see the the object is only hold by this a.

Opinion?

Best Regards, Christian