On Wednesday, May 28, 2003, at 07:48  AM, jan ziak wrote:
> thanks for your reaction, it is a nice one.
>
> i have concluded from your reaction the following: we can state that 
> the
> existence of a #copy method is consequence of having encapsulation ... 
> and if
> we would like to have encapsulation then it forces us to have such 
> #copy
> yourself methods as in squeak.
>
> my reaction and question then is: why do we not allow access to the 
> internal
> state of an object O1 only to the object R which replicates O1 ? the
> encapsulation is not broken in this case because objects expect R do 
> not have
> access to the internal state of O1.


But encapsulation *is* broken with respect to R. That's significant, 
because encapsulation (and it's corollory, polymorphism) is the 
fundamental principal behind object orientation. In fact, it wouldn't 
be a stretch to say that the quality of code (OO or otherwise) is 
determined by the degree to which it enforces encapsulation.

Your proposal above would require a second "replicator" class for every 
class in the system. The squeak image currently has 1280 classes in it, 
with thousands more in external packages. Do you really want to replace 
a few methods on object with thousands of classes? Even if you took the 
time to write all those classes, it would be a nightmare to maintain. 
If you write a special replicator generator, you break encapsulation 
even more, because you remove the ability of objects to override the 
standard copying behaviour provided by Object.

Of course, if having objects copy themselves bothers you so much that 
you want to break encapsulation anyway, go ahead. Squeak is an open 
system, and you can do anything you like. I don't think your changes 
would be adopted by the rest of the community, though.

This thread has gone on too long. I won't post on this topic again.

Colin