Front page | perl.perl5.porters |
Postings from August 2003
On Sun, Aug 17, 2003 at 05:27:51PM -0700, Michael G Schwern wrote:
> On Sun, Aug 17, 2003 at 11:07:15PM +0100, Dave Mitchell wrote:
> > About a year ago, Simon Cozens reported a bug to the effect that
> >
> > { my $x = bless sub { }, 'X'; }
> > sub X::DESTROY { print "DESTROYED\n" }
> >
> > Doesn't call the destructor.
> >
> > Having looked at it, the reason is that the anon sub isn't a closure
> > (ie doesn't refer to any outer lexicals. Thus, the CV is shared rather
> > than cloned, so its refcnt is >1 when $x is freed.
> >
> > Turning it into a closure makes it work:
> >
> > my $y;
> > { my $x = bless sub { $y }, 'X'; }
> > sub X::DESTROY { print "DESTROYED\n" }
> >
> > Simon mentions that "either the documentation or the code are wrong".
> > Since it would be inefficient to fix, and since closureless anon subs
> > are more common that blessed coderefs (I would speculate), I think it
> > should be documented as a misfeature.
>
> Since it is unnecessarily surprising and inconsistent behavior, and since
> the reason for it happening is purely for internal and not language reasons,
> and since we don't want people to start relying on it, and since it would
> be nice if someone could fix it sometime in the future despite predictions
> that it will be inefficient to fix, it should be documented not as a feature
> but as a bug.
>
> Don't document bugs as features. You will hate yourself in the morning.
My initial reaction is to disagree. On second thought, I'm not so
sure. According to my initial reaction, sub {} is a kind of constant
(*unless* it is a closure). Viewed this way, it's perfectly
reasonable that an extra ref be hanging around. But on second
thought, if that is the case you shouldn't be able to bless it.
Either way, the issue is more than just whether it is destroyed. In
this code:
perl -wle'sub cv { sub {} }; my $x = bless cv, 'X'; print ref cv'
either the bless should fail or the second call to cv should get a new
CV (thus printing CODE). And the latter sounds better to me (except
with something like sub :const { }).
Thread Previous
|
Thread Next