[DGD] Dynamic inheritance

[S. Foley]

"Risto Karjalainen" <risto.karjalainen at pp1.inet.fi> wrote:

>I've been thinking of possible solutions for dynamic objects. By dynamic
>objects I mean objects whose type can be altered arbitrarily on the fly, 
>for
>example changing a sword into a door, or even making it be both. One
>possible solution would be to have an object inherit all the possible type
>objects and have flags determine the type(s) of the object, then simply
>cloning everything from it. But I think storing data that might never be
>used is an outrageous waste of resources.

I had similar reservations about using a single "superclass" object for 
these same reasons, but Mr. Winzell was kind enough to quote some skotos 
memory usage statistics that have convinced me that this isn't nearly the 
resource problem I thought it was going to be.  Perhaps he'd also be kind 
enough to post those statistics to this list.

If you still aren't convinced, I've been kicking around an idea for 
minimizing the memory 'waste' of such an inheritance scheme.  Consider a 
system where you have one blueprint object '/obj/thing.c' (THING) that 
inherits all the various modules (inheritables) that will handle all the 
various methods and data you'll be needing.  Instead of having these 
inheritables contain the data/code directly, you could have each inheritable 
have a single item of data, a lightweight object pointer. The various 
functions in the inheritable would pass off responsibility to the 
lightweight object for handling the calls when necessary and when the object 
pointer != nil, or do some default processing when it is nil. So, instead of 
having 300 variables not doing anything in 60 modules for each object, you 
have 60 object pointers not doing anything.  When you wanted to change the 
sword into a door, you'd just call some method on the sword to set the 
weapon inheritable's (or whatever inheritable handles an object's 
sword-ness) object pointer to nil (which I'm hoping the driver cleans up 
promptly).  Then you'd call some method on the sword to clone up the 
lightweight object associated with door-ness and call the various methods on 
the 'sword' to set the data of the door lightweight object.

First off, I'm not sure the gain (if this gets you any gain) from such a 
system would justify the extra overhead (extra call_others, at minimum).  
And beyond that, I'm not even sure this would actually end up saving you 
resources in the long run.  And I haven't considered whether such a system 
is even desireable from a design standpoint, given the limitations of 
lightweight objects.

I think you might be better off just burning the extra memory and saving 
yourself some unnecessary complexity.

--Steve F.

_________________________________________________________________
MSN Photos is the easiest way to share and print your photos: 
http://photos.msn.com/support/worldwide.aspx

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