It’s not non-sensical. If it appeared that I mean for all objects to use
append(), then I was not clear. Using append() was just an example. With
numbers it might mean add_on(). With Strings it might mean Concat(). With
Animals it might mean graft(). With TrainCars, it might mean hitch().
The point is, an object can have another object added to it. The fact that
we do it easily with RealNumbers is only a cultural truism. It is not a
stretch to think of graft() with an Animal. And so it is sensical. 
(for
non-english speakers, it is understandable).
Drew
···
-----Original Message-----
From: Austin Ziegler [mailto:austin@halostatue.ca]
But why does it really, REALLY mean that? Was there a
reason for doing
this? Is it non-trivial to have ‘+=’ mean ‘append()’?
It’s non-sensical. << exists only as Array#<<, String#<<, and
IO#<< and means three different things. Array#<< is the same
as Array#push, IO#<< is similar to IO#puts, and String#<< is
the same as String#concat. Do you wish to create language
exceptions for three classes? How would 1.append(2) work (to
use your notation)? Why should there be exceptions to the
object/language model in this case?
It still remains non-sensical because it then becomes necessary to
create language exceptions for each type – and each new type. With
Ruby’s current behaviour, one only has to:
def +(other)
end
To get both + and += operators. As someone else pointed out, C++
defines + and += separately so that one or the other can be valid,
and they can do completely opposite things, at that. IMO, C++'s
model is the one that’s nonsensical. (While the original C
implementation of += may not be = +, it acts like it.)
I think part of the problem in understanding why it’s non-sensical
is that all variables in Ruby are references to objects. As others
pointed out:
a = "foo"
b = a
b += "bar"
p [a, b]
Under your model, then both variables would have the value “foobar”.
Under Ruby’s existing model, b no longer aliases a, but a new
string.
Ultimately, I think that any language that allows the definition of
+= separately from + is broken because it allows really dumb, really
broken things in exchange for a minor performance quibble. If you
explicitly want performance benefits in string concatenation, use
String#<< – it’s what I do. If I can’t afford to take the chance of
modifying the original value, then I use +=.
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.23 at 15.14.29
···
On Thu, 24 Oct 2002 04:05:44 +0900, Mills Thomas (app1tam) wrote:
It’s not non-sensical. If it appeared that I mean for all objects
to use append(), then I was not clear. Using append() was just an
example. With numbers it might mean add_on(). With Strings it
might mean Concat(). With Animals it might mean graft(). With
TrainCars, it might mean hitch().
The point is, an object can have another object added to it. The
fact that we do it easily with RealNumbers is only a cultural
truism. It is not a stretch to think of graft() with an Animal.
And so it is sensical. (for non-english speakers, it is
understandable).
I totally agree with you. Ruby’s way of doing it makes the performance
decision visible and accessible right where it’s used, whereas C++'s
method opens you up to subtle, difficult to track errors, and
increased complexity in exchange for a performance improvement that
is only sometimes realized.
···
On Thu, Oct 24, 2002 at 04:24:37AM +0900, Austin Ziegler wrote:
Ultimately, I think that any language that allows the definition of
+= separately from + is broken because it allows really dumb, really
broken things in exchange for a minor performance quibble. If you
explicitly want performance benefits in string concatenation, use
String#<< – it’s what I do. If I can’t afford to take the chance of
modifying the original value, then I use +=.
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.23 at 15.14.29
–
Alan Chen
Digikata LLC
http://digikata.com
Hi,
I probably would not call C++ nonsensical and broken; I think it is just a
matter of language design. For example, in Python indentation is
required/enforced by the language; in Ruby indentation is not required but
still most (if not all) of us write Ruby code with nice and
consistent indentation (except for the one-liners, perhaps).
Similarly, Ruby by default enforces certain things that are options in
C++. I think it is true that Ruby restrictions and defaults by far are
safer and more natural, but I will not dismiss the performance gain in C++
as minor performance quibble. For example, if we have large
(numerical) arrays which are static, it is not highly efficient to use
Ruby default Array class; a recommendation is to use NArray, where the
array is actually implemented underneath as a C array. Similarly, there
may be certain cases where the C++ techniques make more sense. As Dave
and Andy wrote in “Programming Ruby”:
“Ruby is not the universal panacea for programmers’ problems. There will
always be times when you’ll need a particular language: the environment
may dictate it, you may have special libraries you need, performance
concerns, or simply an issue with training. We haven’t given up languages
such as Java and C++ entirely (although there are times when we wish we
could).”
Regards,
Bill
P.S. In C implementation, I think it is up to the compiler to decide what
to do with ‘+=’; the C standard does not specify exactly how to accomplish
that; we just know that we are guaranteed the correct result. Granted,
good C compilers may always translate “a += b” as a direct modification of
the value of a, and they may even translate “a = a + b” into “a += b”, in
opposite direction to that of Ruby. C++ is rather different though,
because '+=" may be defined to be different from the corresponding ‘+’
(that’s why C++ may be slower than C).
···
===========================================================================
Austin Ziegler austin@halostatue.ca wrote:
To get both + and += operators. As someone else pointed out, C++
defines + and += separately so that one or the other can be valid,
and they can do completely opposite things, at that. IMO, C++'s
model is the one that’s nonsensical. (While the original C
implementation of += may not be = +, it acts like it.)
I think part of the problem in understanding why it’s non-sensical
is that all variables in Ruby are references to objects. As others
pointed out:
a = "foo"
b = a
b += "bar"
p [a, b]
Under your model, then both variables would have the value “foobar”.
Under Ruby’s existing model, b no longer aliases a, but a new
string.
Ultimately, I think that any language that allows the definition of
+= separately from + is broken because it allows really dumb, really
broken things in exchange for a minor performance quibble. If you
explicitly want performance benefits in string concatenation, use
String#<< – it’s what I do. If I can’t afford to take the chance of
modifying the original value, then I use +=.
-austin
– Austin Ziegler, austin@halostatue.ca on 2002.10.23 at 15.14.29