Re: copy protocol and object ravioli

[Roger M. Burkhart]

>From Glen's message:

> But, if I take off my programmer's hat and replace it with my
> "abstract modeller's" cap, I still have to wonder why the 
> object is responsible for cloning itself.  Nothing in the
> world from which we abstract works that way....except for
> living organisms...

And even if organisms clone themselves, they don't do so without some
help, at least consuming some materials from an environment, and
reappearing as new elements of that environment.

> So, it's not the mechanism of self-directed cloning that upsets
> me.  It's the fact that an agent shouldn't clone itself unless
> that cloning process is part of the model being simulated.

Yes, I agree that the model needs to specify explicitly what is involved
in the appearance of a new individual, and this may be more than just
cloning some fixed notion of internal state.

>From Manor's earlier message:

> I may be underestimating the problem here but wouldn't the following
> simple heuristic do the trick?

[suggestion for language extension to annotate "unique containment" deleted..]

> If an object doesn't know, at compile time, what subset of its contents
> is shared (in principle), then the programmer is not thinking things
> through - which is negligent in the old fashioned single-threaded world,
> but is downright criminal when you have threads.

The new zone allocation apparatus does contain an extensive facility for
tracing down all internal state of an object, whether contained in subobjects
or only in raw malloc-style allocations, and it's this tracing that supports
deallocation of complex objects under drop.  (Currently this apparatus is
only used by the defobj, collections, and activity libraries.)  I agree
that from an implementation point of view, an object does need to be able
report all the internal computational resources that its existence as an
object representation entails.

But this is different from the modeling point that Glen raises about the
sort of cloning processes, if any, that actually make sense as occurring
within a model.  Glen's point, I think, is that many if not most models
really don't have any model-level event that consists of cloning an
existing individual.  Most individuals (we can find examples close at
home) are produced through a more complex process of generation, and it's
only the actual processes for generating individuals that belong within a
model.  Mechanisms like cloning of object state may be used to help
implement the creation of a new object representation, but they're part of
the computational implementation, not meaningful events in the model itself.

> ...Well, there must be some major source of complexity that I'm overlooking
> here, right? So, what am I forgetting?

The fact that cloning doesn't actually occur in most modeled worlds,
as Glen said.

> PS> I'm forgetting something in the sauce, right? :*)

The creation of the individual may involve all kinds of relationships to
other chunks in the sauce that care about tracking it.  Your suggestion for
a registration protocol is just one way of accomplishing this that may be
relatively awkward compared to the environment itself helping in the
delivery and attachment of the new object.  So it comes back to the
environment taking responsibility for the delivery, for which even the
notion of the object having "delegated" this responsibility, as in Scott
Christley's "DelegateCopying" protocol, could be a bit misleading.  The
fact is, many objects may never be responsible, or even much involved,
in their own creation.

>From Manor's second message:

> Let me get this straight: are you saying that, if for example, I am
> simulating a soldier in battle, and I assume that soldiers don't
> clone themselves during the actual fighting, then I am not allowed
> to give their software counterparts the ability to clone themselves
> on the basis that it is not part of the model being simulated?

If you're going to rely on low-level operations on an object's implementation
like cloning, you should be careful to distinguish those from meaningful
events in the model.  You should also consider whether every object
creation you want to have happen should even be initiated or orchestrated
from within the object being created; even from a strict implementation
point of view it may be more effective to do it somewhere else.

All of which means that the notion that every object should have its own
copy implementation is not necessarily justified.  This discussion has
pointed out, however, that if there is a generic copy implementation, it
need not be only a surface, "shallow" copy, but could use the same mapping
of internal allocations currently used for drop, once these mechanisms are
better documented for wider use.

-Roger