on 2/4/02 10:13 PM, [EMAIL PROTECTED] purportedly said:
> No. Not with the current Perl internals. This is an important issue
> and will be addressed in Perl 6. If you need to enforce an order,
> undef the variables in a particular order.
Actually, it appears that in certain circumstances Perl is *not* cleaning up
when it should. Take this situation (which happens to be mine):
$self->sub1;
sub sub1 {
my $obj = new SUPER;
$self->sub2;
return
}
sub sub2 {
# SUB is subclass of super, but has its own destroy()
my $sub_obj = SUPER::SUB;
return
}
In this case, Perl is destroying SUPER before SUPER::SUB, even though the
latter goes out of scope first. Both destroy methods run, and there are no
circular references that I can find (I know for a fact that I have no
references to references, at least). Is it that the interpreter is faster
than the collection system, and at the point that Perl catches up it
destroys in any order?
My problem is that the sub object must be destroyed before the super or an
exception occurs. It works if I explicitly undef the object, but shouldn't
leaving scope do this?
It is awfully clumsy and inelegant to have to undef the object before
leaving scope every time. In my case I have many places where an exception
could occur that would require a premature return from the subroutine.
I also found out the hard way that you cannot call new() on a subclass from
within a parent class, at least if the constructor is inherited and both
packages are defined in the same file.
Keary Suska
Esoteritech, Inc.
"Leveraging Open Source for a better Internet"
