Wed, 17 Jul 2002 02:47:08 +0900, Hal E. Fulton <hal9000 / hypermetrics.com> pisze:

> In a "radically object-oriented" language like Ruby, it seems natural
> that assignment *would* be a method (as it is even in C++ and Java).

It would not make sense in a language like Ruby (and almost all
other languages, including Java) where variables reference objects,
not contain objects.

Only C++, C, Pascal, Perl and some older languages are different.
Because they copy objects passed around the program unless explicit
pointers/references are used to indirectly refer to them. In C++
here:

    std::string x;
    std::string y;
    x = "some string";
    y = x;

x and y are different objects (they can at most share their payload
by a complex machinery under the hood), and 'y = whatever' doesn't
create a new object for y but changes contents of an existing object.

It's hard to share objects in C++ because of explicit memory
management. You would have to know when other parts of the program
are no longer interested in an object. It's easier to make a copy
and destroy each separately.

C++ encourages imperative programming. Sharing is troublesome and
copying is expensive, so you often modify objects in place.

That approach worked well where most objects are simple things like
numbers. It gets much worse with tree-like structures which like
to have shared parts.



In Ruby objects are naturally passed by reference, explicit pointers
with an additional indirection are not needed. When you store an
object in a data structure or in a variable, only a reference to an
existing object is written, there is no copy created.

It's common that two variables refer to the same object. If '=' was a
message sent to that object which replaced its contents with contents
of another object, the change would be visible through both variables!

Well, it would be worse: you couldn't express that sharing at all.
If assignment made a copy, how would you refer to an existing object
to see changes done inside it? Would passing objects as arguments
perform the same copying? Now it's the same as using '=' to bind them
to parameters!

You don't modify the object inside the variable. You modify the
variable to let it point to another object. It's a fundamental
difference. It allows to have one mechanism of passing objects around
and holding them with variables.

Since sharing is common, modifications of objects in place are more
dangerous. You might forget that another part of the program refers
to that object while it was meant to have a snapshot of its state
from an earlier time. You either use methods which treat objects as
immutable and return new objects with changed contents (those without
'!' at the end), or remember to .dup objects as needed.

These are two basic models of passing objects around. They shouldn't
be confused, you can't take parts of one system into another. The
difference is quite fundamental and easily forgotten, because in
overall it causes similar effect in case of assignments of atomic
objects like numbers (immutable in Ruby, mutable in C++).

-- 
  __("<      Marcin Kowalczyk
  \__/     qrczak / knm.org.pl
   ^^    http://qrnik.knm.org.pl/~qrczak/