Re: Copying an object

["Mark Hadfield" <m.hadfield(at)niwa.cri.nz>]

David Fanning <davidf@dfanning.com> wrote in message
news:MPG.1235bac4bdaa96e89898d1@news.frii.com...
>
> ...insurmountable problems. Randy Frank,
> who wrote much of this object code when he was at RSI,
> has sent me a private e-mail outlining even more problems
> than I was aware of on my own. For example, he points
> out that many times the model objects (which is what
> we were discussing earlier this morning) have parents.
> What should be done about those? Should the copy have
> the *same* parents, or any parents?

Remove the model object from its parent, copy it, and add it again
afterwards. Or am I missing something?

Entirely general solutions are very hard to come by in the object-oriented
world but if we know that an object is, say, an IDLgrModel, then we know it
has one parent (at most), we can get a reference to the parent from the
child's PARENT property, and we know the parent has Add and Remove methods.
Of course if I wanted to be perverse I could write an object that inherits
from IDLgrModel (so returns true for OBJ_ISA(...,'IDLgrModel')) but doesn't
obey these rules. But I don't want to be perverse.

> You can also try SAVEing and RESTOREing your objects,
> but this has the problem that sometimes the methods of
> restored objects can't be found. (See JD Smith's comments
> on this on my web page.)

That can certainly be a problem if you RESTORE an object that was SAVEd in a
previous session, but surely it is not an issue in the present case, where
we want to make a copy of an object (or object tree) that was created in the
present session. The copy operation needn't change any of the object
definitions, method definitions or object-method bindings.

---
Mark Hadfield
m.hadfield@niwa.cri.nz  http://katipo.niwa.cri.nz/~hadfield/
National Institute for Water and Atmospheric Research
PO Box 14-901, Wellington, New Zealand