Re: storage management

[Michael McClary <michael>]

The Dean/Mr Hill idea is nice.  A few caveats:

> [] statically
> declare a heap object.  All objects allocated at or below that scope
> get allocated in that scope's heap.  When the heap goes out of scope,
> it destroys itself. These resemble Lifetime objects for more than one
> object. More permanent objects can either be made, then promoted out
> of the heap, or explictly allocated on a different heap (using the
> fluid binding trick currently implemented).  The promotion operation
> is essentially: "ensure that object O is in a heap with a longer
> lifetime than heap H."  

 - Actually, the promotion operation should be the message "transfer
   yourself to THAT heap scope".

 - Making all allocation on the episode heap will break existing code.
   Instead, a NEW_FOR_CURRENT_EPISODE(Foo) is needed, and perhaps a
   NEW_ON_THAT_HEAP(heap,Foo).

Easy hack:  Replace the hidden allocation header on the allocated space
with a "space object" that accepts messagees to link itself (doubly) onto
a queue, unlink itself, or move itself from one queue to another (which
is why the queue is double-linked).  Messages are sent to the "space
object" aspect of a heap-allocated object by macros defined in the
allocatior's .hxx file, which does the necessary pointer magic to get
to the hidden object.

NEW(Foo) doesn't invoke the link-yourself message.
NEW_FOR_CURRENT_EPISODE(Foo) gets the queue to use from a fluid var,
and NEW_ON_THAT_HEAP(heap,Foo), of course, is told.  A macro for
establishing a new episode plants a bomb that deletes all the objects
on the queue.  The automatic delete can be LIFO for minimal
side-effects.

(The "space object" can also encapsulate the allocation behavior, and
 maintain free lists, trees, etc.  Boot it up by allocating one chunk
 of memory and creating an initial object on it.)

	michael

PS:  Deallocating heap storage was the original inspiration behind
the demolition package.  It's nice to see it being used for that
now and then.  B-)