Colin Putney pondered this reaction to my question:

On Fri, 23 May 2003 12:35:16 -0700, Colin Putney wrote
> I myself have never seen anything copied. Ever. What is copying, 
> after all, but the creation of another thing that is identical to 
> the original. This is impossible, because you cannot have to things 
> which are the same in every respect. So the best we can hope for is 
> to create another object which resembles the original in all the 
> respects that we care about.
> 
> In the case of a glass, this might be as simple as "can also hold 
> water," a purely pragmatic definition of glassness. If we are 
> holding an elegant dinner party, we might also care about shape, 
> size, weight, and color to ensure that our place settings look good 
> on the table. If we are chemists, we might care about the heat 
> conductivity of the glass.
> 
> In the real world, objects have no intrinsic definition. We can 
> define properties we are interested in and compare objects with 
> respect to those properties. But the objects remain what they are 
> regardless of how we represent them in our minds. Similarity is in 
> the mind of the comparator. So the act of copying requires a mind  - 
> a context, as you say - to define the parameters of the copying operation.
> 
> In contrast, Squeak objects do have an intrinsic definition. They 
> are defined by their class. Other object-oriented systems have other 
> methods of defining objects, but they all use a definition of one 
> sort or another. In order to better simulate the real world, we use 
> the principal of "encapsulation" to hide that definition from other 
> objects. For practical reasons, encapsulation isn't strictly 
> enforced, we find it useful to break it every now and then - in 
> inspectors or the debugger, for example. But for the most part, we 
> want to treat objects as opaque. Like objects in the real world, we 
> (and other objects in the system) cannot know their essence.
> 
> This presents a problem for your idea of an external copier, copying 
> the object according to it's context. Objects in Squeak are really 
> very narrowly defined, unlike the real world which seems to be 
> infinite in it's depth and richness. You can't examine the object in 
> arbitrary ways, you can only do so in terms of it's definition - its 
> instance variables, its methods, its class. But that would break 
encapsulation.
> 
> Luckily there *is* something that can examine an object with out 
> breaking encapsulation - the object its self. So in fact, it's quite 
> reasonable to have an object copy its self. It's the only thing that 
> can do so.
> 
> Does that clarify anything?
> 
> Colin

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.