Hum hum hum. What exactly does "destroying" mean in Perl 6? As memory
is managed it probably refers to invoking a finalizer..?
If yes, then you could also use an explicit construct such as C++'s
auto_ptr<> & the likes (read: an "auto" declaration), C# using()
mechanism (read: a "block statement" thing which gets expanded to the
perl equivalent of foo = ...; try { ... } finally { foo.Dispose(); }
or simply implement a using function (or the more general
UNWIND-PROTECT, as in CL).
Latter would have the advantage of not requiring extra syntax.
- Michael
On Sat, 15 Jan 2005 01:28:22 +0000, Shevek <[EMAIL PROTECTED]> wrote:
> In which Tigger maintains that code relying on timely destruction in
> perl5 is buggy [and relatively rare], and agrees wholeheartedly with
> Rabbit on almost everything else.
>
> On Fri, 2005-01-14 at 17:52 -0700, Luke Palmer wrote:
> > Shevek writes:
> > > The example you described destroyed a ref within a sub, and then assumed
> > > that the object refed would be destroyed at scope exit.
> >
> > I'm assuming you're referring to my Perl example, which you tactfully
> > omitted in order to lose the casual reader. Very cunning. :-)
>
> My mistake, I was too heavy with [del]. I meant to put it back in.
>
> > Here it is again:
> >
> > my %data;
> > sub a {
> > open my $fh, "> somefile";
> > $data{fh} = $fh;
> > }
> > sub b {
> > %data = ();
> # $fh is destroyed here, not at scope exit
> foo();
> bar();
> # not here.
> > }
> > a();
> > # ...
> > b();
> >
> > And what I mean is that most approximate solutions won't destroy $fh in
> > time. One example of such a proposal is keeping tabs on objects in the
>
> Timely destruction in C++ (I think the only language we have mentioned
> which _officially_ implements it) only happens at scope exit. "Timely
> destruction" in Perl5 happens (probably) kind of when the ref goes away,
> although I don't think even that is guaranteed, my memory of temporaries
> and targets is too fuzzy.
>
> > current scope which need timely destruction and then do a sweep whenever
> > we lose a reference to one. Another is using generational schemes.
> > Generational schemes are good for finding *enough* dead objects quickly
> > when we run out of memory, but they're not good for finding whether a
> > particular object is dead.
>
> But they may be adequate in a pinch for handling many simple cases of
> timely destruction. However we are likely to dig the same hole as perl5
> where programmers rely on the behaviour [see bottom].
>
> > However, Perl 5, since it uses refcounting everywhere, has no problem
> > with this. Parrot has decided not to use refcounting at all (a decision
> > that I think I agree with), and so we have this problem.
> >
> > > This is incorrect: the object refed should be destroyed when the ref is
> > > destroyed in a general refcounting GC system.
> >
> > And I don't understand what you mean here.
>
> The example above demonstrates.
>
> > > Anyway, this led me to the (useful?) thought that you could delink the
> > > concept of timely GC and destruction at scope exit by registering
> > > atexit() or atleave() code on a scope (like finally{}) which explicitly
> > > undef'd registered PMCs. That way you would be able to guarantee
> > > destruction even if the PMC was still ref'd, which is probably more use
> > > for things like critical section locks than just relying on a
> > > side-effect of the GC, and is certainly easier to implement since it's
> > > just a flag on the lexical in the pad.
> >
> > Precisely! But if we have to support this area of Perl 5 (I'm not
> > certain that we do yet), we have to implement its semantics
> > backward-compatibly. The programmer of Perl 5 relied on the side
> > effects because they worked then. So we're not allowed to break them.
>
> I maintain that relying on those semantics is a clear violation of the
> documentation, as explicitly stated somewhere I can't immediately find,
> but someone else must be able to find the passage. Such code may be
> considered broken. I also suspect it's not a hugely common case.
>
> > And because of Perl 6's many lexical scope hooks, I hope that we can get
> > rid of any timely destruction policy, to encourage the use of lexical
> > hooks instead of destruction rules.
>
> Yes. Lexical hooks good.
>
> > No matter how we slice it, it would royally suck to add a sweep at the
> > end of every lexical scope.
>
> I wouldn't worry too much about a last-generation sweep at that point,
> especially if we know which zones are in scope (as opposed to extent) at
> that time. However, I doubt anyone is going to implement this.
>
> S.
>
>
