From: Marcin 'Qrczak' Kowalczyk Date: 2002-08-03T20:59:05+09:00 Subject: Re: TkText no -textvariable workaround? Wed, 17 Jul 2002 02:47:08 +0900, Hal E. Fulton 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/