[DGD] Re: Copying objects in DGD

[Par Winzell]

> So the best way to do it would be to offer "copy" as a member function, 
> kind of like create, that each object calls its base class and then 
> copies any further values (and should probably make sure its the same 
> type of object). Doesn't seem to horribly reliable, because if one 
> inheritable or object fails to implement it properly, its would either 
> fail or be inconsistant, but, if implemented properly, it *should* work 
> just fine...

I think the simplest approach is to have an import_state() and an 
export_state() style functionality -- the object can implement those 
themselves, or there can be an external module that 'knows' about 
various object types and which queries to call to fetch the state.

I've done the former in the past, but we do the latter at Skotos -- for 
each object there is a bunch of information that tells the system which 
queries to perform, how to iterate over the results of certain queries 
and thus collect the state. That particular structure is also very nice 
for representing in XML, which was one of the original design decisions.

There are other reasons to keep this functionality at the LPC rather 
than the DGD level. For example, if you made a 100% duplicate of an 
object that's in your inventory, then the new object would most likely 
contain an object pointer to you as its 'environment', but you -- the 
environment -- would not have been informed of the sudden existence of 
this object, and would not have the new object in its inventory array 
(or however the data structure is constructed). There are many examples 
of such data structures of course.

Putting this functionality on the LPC level enables you differentiate 
between what I consider transient state such as object environment, and 
configuration state such as descriptions, weights, etc.

Zell

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