On Thu, Jul 28, 2005 at 01:08:13 -0000, David Formosa (aka ? the Platypus) wrote: > On 26 Jul 2005 05:18:05 -0000, David Formosa ) > <[EMAIL PROTECTED]> wrote: > > > We are should have an API to talk to the GC and give it hints about when it > > should run, and tweek the verious paramitors for its running. > > > > For example > > [...] > > Also > > my Bigobjet $big is GC::timely = 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.
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.
What we want is features:
some object needs to die appropriately, because i'm using
DESTROY to manage resources, or trigger an action
And we can also open the door to optimizations:
some object is cheap to store, you can collect it later than
usual
everything under this object belongs to it, and only to it (that
is, you can cleanup the whole tree when cleaning this up)
and so on and so forth.
We do need this applying to:
roles and classes:
class Moose is GC::timely { ... }
a policy for attributes of objects:
class Moose {
has $. handles "method" is GC::timely; # not good enough, i
# want to be able to say "all children", and I want this to
# be inheritable... A class property, i guess
}
instances:
# your syntax is per container
my $big = $something but GC::timely; # do we have runtime 'does'? I
keep forgetting
contained elements within a container
my @a is Array of (Item is GC::timely);
and containers themselves without respect to their contained:
my @a is Array is GC::timely
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me dodges cabbages like macalypse log N: neeyah!
pgp7hENFCf619.pgp
Description: PGP signature
