virtual data slots (copy-on-write data inheritence)

[Bill Burdick <burdick@ars.rtp.nc.us>]

I was just reading a byte article about newtonScript, which looks to be a lot 
like Self, and it mentioned a copy-on-write style of data inheritence.  I've 
used that type of inheritence before, and I thought it was pretty useful for 
inheriting defaults and saving space.  I think it would be pretty easy to 
implement in Self, but I was wondering how expensive adding slots on the fly 
would be.  The easiest way I can think of to implement this would be to use 
addSlotsIfAbsent: in conjunction with assignment.

Actually, this is a pretty neat model to use for standard data inheritence: 
have a prototype tree and make 'instances' inherit from their data prototype, 
with slots appearing in the instance as needed.  One advantage of this is that 
new defaults would take effect in current instances.  You could also find out 
what objects are instances of what prototypes (you could do that now, but there 
doesn't seem to be any other point to making instances point to their 
prototypes).  Maybe the overhead for this would be acceptable, given that it 
only occurs on the first assignment to a given slot.  You'd have to make a new 
assignment method along with the new data slot, so that further assignments 
didn't cost more than an assignment does now.  Could you do it so that the new 
assignment method doesn't generate a new 'class' for the object (I forgot what 
you call those implicit repositories of methods that clones share)?  If this 
isn't too expensive, removing the slots to make them go back to the defaults 
should have an analagous cost.

This fits with my current mission to virtualize as much data as possible in my 
project right now.  I don't know when I started with this -- I think it was in 
1989 or 90 (before I used Self at all).  We were writing a MUD (I hope this 
doesn't damage my credibility) and I found lots of redundant data hanging 
around.  When I virtualized the data (implementing the copy-on-write 
inheritence for sludge), it really cut down the memory usage.

I've done that with Smalltalk, for our knowledge rep system, and when I 
'virtualized' the the relations (kind of like slots) in just the classes that 
we have, it went from 6500 relations to 250.  This was a savings of 2 meg, for 
our system (we have a lot of descendents of PhysicalObject, which has bunches 
of relations on it, like mass, temperature, etc.).  These relations were just 
the ones on the classes, not on the instances, so the potential savings on 
instances would be immense.

Any comments, anyone??

	-- Bill Burdick
	burdick@ars.rtp.nc.us