On Wed, Dec 06, 2000 at 01:15:07PM -0500, Dan Sugalski wrote:
> What I'm thinking is that we'll have a scoped destruct stack that gets
> pointers to variables that explicitly need destruction, and as we exit
> levels of scope we call the destructors of those variables that need it.
> (They can still be GC'd later to pick up their now-free memory) Most things
> won't get tossed on there, since most variables don't have any destruction
> behaviour.
The one specific case that someone (sorry, forget who, not kept that e-mail)
mentioned was using objects to hold "expensive" things such as database
handles that you want closed as soon as the last referent stops using them
("Would the last person leaving please turn out the lights")
Stack based destructors as you described them would fire as soon as any
reference went out scope?
[hmm. am I thinking too much like perl5 here]
sort of explicit call to DESTROY, akin to anyone walking out the door
turning the lights out without checking if someone else is still there.
and just leaving it to the GC would ensure that the lights remained on
while people were in Seattle^Wthe room, but might mean that they stayed
on for quite a while after the last person left.
However, for the case of a shared object wanting the refcount behaviour,
would it be easily implemented with the primitives you describe?
[scope stack, lazy garbage collection] for example a module using one
hub object with (perl) methods to maintain a refcount, and a second class
of spoke object with copied instances sitting on each scope stack to
decrease the hubs reference count at the correct time.
(ie am I right in thinking we can implement a solution to "Would the last
person leaving please turn out the lights" without needing reference counts
in the core SV)
Nicholas Clack
