Lars Christensen wrote:

> + is a method defined in terms of +=, so that "a = b + c" is equivalent to
> "a = b.dup; a += c". In case of string appending or even Numeric addition,
> a more efficient implementation can be made by allowing + to be overloaded
> (like C++).

> This may be a drastic change, but I would vote for it.  This would be much
> more natural in my C mind than current Ruby. Methods that modify the state
> of the object are even common in Ruby and are indeed "object oriented".
> Avoiding them is "functional thinking" IMO.
>
> --
> Lars Christensen, larsch / cs.auc.dk

I proposed about the same thing in May (See mail 15166,15197,15262 and
followup mails).

Especially interesting was the posting of Masa Tanaka (15305).

He pointed out that the above approach is not always optimal.

The best way would be to let the compiler optimize away the temporaries.

(I will assume that += has the semantic you proposed.)
E.g the following expression:

c=a+b+d

would be optimally parsed as:
c=(a+b). # creates a new object
c+=d     # only modify existing object

(In fact the most optimal solution would be to apply a three variable
 add(a,b,c) operation, but then it would be endless story...)

The bad thing about this that the compiler would have to assume
that this optimization is right, but in fact it depends on the
implementation of the operators + and +=.

I would still welcome such features in Ruby, but it is not a pain
to live without them.

I also think that changing the meaning of existing operators is not OK.
Instead I would propose the new operator +=! which modifies the object
itself.
So, one could maintain backward compatibility.



To the ++ operator: I completely agree that this is superflous, misleading
and
just an excuse for writing more cryptic code.
I try to avoid it in C[++] either, (expect for loops).


Christian

--
signature file is under construction