[DGD]kernel cloning and inheriting

[Stephen Schmidt]

On Thu, 15 Feb 2001, Erwin Harte wrote:
> It has to do with practical limitations.  The compile_object() kfun
> can be used to compile an already existing object in-place, but you
> cannot re-compile an inherited object.
> If you would allow an object to be cloned -and- inherited, this would
> lead to situations where you are basically stuck: You cannot re-
> compile the object because it is inherited, but you need to destruct
> it, compile it, and re-compile (or destruct + compile) any objects
> that in turn inherited the original object.

Let me see if I have this straight; I'm pretty sure at
some level I don't. Consider three objects, A, Ac, and B.
Ac is a clone of A; B inherits A.

1. You can recompile B because nothing inherits it.
2. You cannot recompile Ac because it is a clone; to recompile
   Ac is basically to recompile A.
3. You cannot recompile A because B inherits it.
4. You could recompile A if you first destructed B, but then
   object B would be lost. In a persistant world, the loss of
   B during the recompilation of A could be problematic.
5. You could recompile both B and A if Ac did not exist. (?)
   The root problem is that if you try to recompile A in
   the presence of Ac, then Ac is forced to change along
   with B, and Ac might not want to do that.

I don't think I have 5 right. Why does the existence of Ac
make it impossible to recompile the inherited A object,
when that would be possible if Ac did not exist? It must
have something to do with Ac re-using A's code, but what
would be the harm if the recompiling of A simply changed
the behavior of Ac?

Or, why is it that you can recompile A if Ac exists but
B does not?

> Of course, from a conceptual point of view it doesn't hurt to keep the
> different 'types' of objects separated.

Most certainly.

Steve





List config page:  http://list.imaginary.com/mailman/listinfo/dgd