On Thu, 28 Jul 2005 16:22:19 +0300, Yuval Kogman <[EMAIL PROTECTED]> wrote:
[...]
> On Thu, Jul 28, 2005 at 01:08:13 -0000, David Formosa (aka ? the Platypus) =
> wrote:
[...]
>> my Bigobjet $big is GC::timely =3D Bigobect; # Request timely
>> # destruction of $big. Usefull for filehandels and network
>> # resources.
>
> I like this approach the most: it let's users specify what they
> need, not how they need it done.
I can see advantages to both approches. All GC systems have a hit
when they run, in some situations it would be nice to shift the hit to
times when it doesn't mattor that much. For example a GUI app may
delay the GC till when the user has been idle for a while.
> Every GC has slightly different semantics. If we have a generational
> GC that has delays, or a reference counting scheme that does
> occasional reachability tests, it doesn't really matter.
Yes thats why I was saying "hints". Not all hints are going to be
that meaningfull.
> What we want is features:
>
> some object needs to die appropriately, because i'm using
> DESTROY to manage resources, or trigger an action
Which I'm calling the timely trait.
> And we can also open the door to optimizations:
>
> some object is cheap to store, you can collect it later than
> usual
Sort of an anty timely? GC::tardy
> everything under this object belongs to it, and only to it (that
> is, you can cleanup the whole tree when cleaning this up)
GC::tombstone;
[...]
> We do need this applying to:
>
> roles and classes:
> class Moose is GC::timely { ... }
Yep (and yes to all your other suggestions).
--
Please excuse my spelling as I suffer from agraphia. See
http://dformosa.zeta.org.au/~dformosa/Spelling.html to find out more.
Free the Memes.
