On Sat, 2002-08-03 at 05:59, Marcin 'Qrczak' Kowalczyk wrote:
> 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


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