[DGD] DGDMP 1.1.10

[Shentino]

On Tue, Jun 9, 2009 at 11:50 AM, Felix A. Croes <felix at dworkin.nl> wrote:

> Shentino <shentino at gmail.com> wrote:
>
> > Error was "Too many objects inherited"
> >
> > I only have (11 + 11 + 2) = 22 inheritables involved, yet I was able to
> > create an inheritance tree that triggered this.
>
> The error prevents overflow.
>
> DGD flattens the inheritance tree into an array.  For implementation
> reasons, when C and D both inherit A and B, an object E which inherits
> C and D must have the slices ({ A, B, C }) and ({ A, B, D }) in its
> inheritance array, so inherited objects may appear there twice, or
> indeed many more times.


Is there any way to collapse redundancy out of this?  Perhaps with
indirection or with a tree instead of an array?  I bet there's a gazillion
copies of AUTO and/or SECOND_AUTO floating around in that array.

Especially for ubiquitously inherited libraries such as utility libraries or
auto objects that can at present easily multiply inheritance footprint with
a one line tweak in ObjectD, with the effect even more pronounced if you
have different "users" such as System, Common, Game, and so on doing their
own layers.

And for the ultimate in inheritance drama, consider Skotos's THING.  Proper
subobject encapsulation would imply about maybe 20 interfaces each
abstracting 20 implementations with their own hidden variables.  With first,
second, and maybe even third autos added to the mix an advanced blueprint
could easily burn up thousands of bytes in inheritance if common ancestors
aren't deduped somehow.

DGD uses a byte to index the inheritance array.  DGDMP can use two
> bytes for the index.
>
> I've thought for a while about ways to improve on this, but all of
> them trade interpreter speed for a supposedly common-case optimization
> that can still be defeated easily by a specially crafted inheritance
> tree, even with a 16 bit index.


Even assuming that the inheritance array paradigm is here to stay, I would
propose leaving it up to the end user to specify this by making it a tunable
data type in config.h, much like eindex and uindex currently are.  Barring
any hidden snags I don't know about, this would seem reasonable even as a
short term fix.

Unless the interpreter is somehow hard locked to the data type used to index
the inheritance array this would seem to be a viable option by placing the
onus of trading speed for flexibility upon the end user.



My main motivation for using liberal inheritance structures is to implement
good abstraction and encapsulation, kinda like api objects on steroids.
 When dealing with objects in the "world", things can get hairy in a hurry
and I would much rather not cram different sets of functionality into a
single and implicitly self-trusting package that has a side effect of being
too messy to maintain easily.

The case I showed you was a simplification of something I actually ran into
while I was doing kotaka.  I had several sublibraries, for geometry, id,
inventory, properties, exit handling, combat, and so on.  Breaking things up
into interface and implementation was a big help in making sure that one
part's variables didn't get tinkered with by another part's functions.  It
also made the code much neater and easier to
maintain.  I was quite saddened when I was forced to smoosh things
back together again because I overflowed the compiler.
 Not long afterward, things got messy enough for me to gut the whole thing
and write it again with less functionality.