inheriting data slots

[burdick@mentor.cc.purdue.edu (Bill Burdick)]

Write once slots would do it, but I don't see why adding the slots of data
parents of prototypes would slow things down.  Maybe my first letter wasn't
clear...

You don't need to add the slots of data-parents at 'run-time,' that is, you
only need to do this in order to construct the prototypes, not to construct
the clones.  Once you have all the slots in the right places, you can just
clone the prototype and everything is fine.

For instance, if you have a 2-d point (with slots: parent*, x, and y) where
parent holds traits point, and you want to make a 3-d point (with slots
parent*, x, y, and z), where parent holds traits TDpoint, you can construct
the prototype in these three ways (there are more, but here are 3):

1) make it by hand; just define it as (|
	parent* = traits TDpoint.
	x = 0.
	y = 0.
	z = 0
|).   This will work, but it makes for unmaintainable code -- you'd
probably end upwriting a script to propogate changes in data parents
to the children prototypes.

2) use a data parent and redefine copy: (|
	parent* = traits TDpoint.
	dataParent** <- prototypes point.
	cloning*** = traits deepClonable.
	z = 0
|)  where deepClonable contains rules for copying through data parent
slots.  The problem here is that dataParent is assignable and so it
will slow down access to data in slots inherited from the dataparent.

3) use _AddSlots: and _RemoveSlots: like this (this is using the old
conventions):
prototypes _DefineSlots: (|
	TDpoint = (|
		parent* = traits TDpoint.
		z
	|)
|)

"inheriting is a global variable"
inheriting: prototypes point copy
inheriting _RemoveSlots: 'parent'
prototypes TDpoint _AddSlots: inheriting


Using method #3, you get a prototype with all the slots it 'inherits'
from its data parent, and you can use it with good performance.  This
is possible right now, but it's a little clumsy -- it would be easier
to maintain (and prettier) if we could use _AddSlots: and
_RomoveSlots: from within methods so that the inheritance code could
be one message instead of three (and you wouldn't need