copy yourself?
jan ziak
ziakjan at host.sk
Wed May 28 14:48:59 UTC 2003
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.
More information about the Squeak-dev
mailing list
|