It would not make sense in a language like Ruby (and almost all
other languages, including Java) where variables reference objects,
not contain objects.
no, i think you take this too far. it makes a lot of sense in a language
like ruby, but does require a seperation between assignment and
reassignment, if you will. in other words x = “a” would not necessarily
be the same as x = String.new(“a”), [of course a new literal could be
used] in the later case you are creating an object, x, and making it a
string. in the former you are reassigning the object, x.
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.
unfortuanltly a couple of ruby objects are not passed by reference,
notably FIXNUM. personally, i have already run into a couple instances
where this “knocked me off my horse”, and i think it a bad idea to mix
things up like this. perhaps there is good reason, but if it is one of
speed, i’d rather buy a faster processor and more memory that have this
inconsistancy.
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!
yes, but not replacement of contents.
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!
no, no copying.
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.
(aside, would it be possible for ! methods to be an automatic creation?
just seems like there might be a way to define a method such that the !
version of it is automatically is deduced from it and that this could be
used through out ruby. just a thought.)
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++).
i think there are some deeper consideration to this. if ruby were to
take one more step in the direction of OO, becoming a Radical OOP, i
think it would discover another level (or at least semi-level) of power.
since everything is a subclass of object, there’s no reason that objects
can’t switch identities above that. we would be able to call-back on
such reassignments and create all sorts of neat “automagical” stuff.
also one could conrol class access at a much finer level.
it would not force us to use pass by assignment instead of pass by
reference. in fact the opposite is true.
~transami
···
On Sat, 2002-08-03 at 05:59, Marcin ‘Qrczak’ Kowalczyk wrote:
–
__("< Marcin Kowalczyk
__/ qrczak@knm.org.pl
^^ Blog człowieka poczciwego.
–
~transami
