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.