mirrors (was: [self-interest] Adding method slots dynamically)

[Jecel Assumpcao Jr]

Toby Ovod-Everett wrote on Thu, 18 Aug 2005 06:45:02 -0800
> In addition, by putting copying in the domain, one makes it easier to override
> the copying behavior.  It is rare that an object designer would want to
> override the behavior of addSlots, for instance.  It is not that rare that a
> designer would want to override the behavior of clone, on the other hand.

This is a very good point.

> Yes, if one puts clone in the mirror, one can still override the behavior of
> clone by overriding the behavior of reflect so that it returns an modified
> mirror that overrides clone on it's behalf, but that is a convoluted approach
> to implementing a common design pattern.

Yes, and a similar argument can be made for putting "printString" in the
objects themselves even though it is also a very meta operation. If you
need a different mirror of every object you might as well include that
stuff in the object.

> The most common reason to override clone is a need to retain a count or a list
> of every object of a given "class".

Another reason is to control how deep the copying should be. The raw
clone operation is what is called shallowCopy in Smalltalk. Sometimes
you don't want to share subparts with the original but want to copy
those too. This makes coming up with a generic copying framework
complicated and is related to the problems of saving a single object to
a file and reading it back in. It is easier if the objects at least help
with part of the job.

-- Jecel