[Bioperl-l] my todo list

[Hilmar Lapp]

Jason Stajich wrote:
> >
> > Now I see. The DESTROY in IO.pm wasn't executed because it came
> > second in multiple inheritance, right? Does this mean that a
> > DESTROY method is potentially harmful in RootI.pm? Not good, even
> > though we don't need it yet. So, assuming my guess of the reason
> > is right, can we add a method _io_cleanup() (or whatever name, but
> > not a very common one) to IO.pm, and in RootI.pm a DESTROY method
> > that calls $self->_io_cleanup() if $self->can('_io_cleanup').
> 
> Exactly!  This took a little digging.  I think the choice may be dependent
> on the order in the ISA.  This is why C++ only allows inheritance from a
> single object.  Actually proper behavior would be to either change the
> order of the ISA list so the Root::IO comes first OR make the object just
> inherit from Bio::Root::IO since IO isa Bio::Root::RootI.  OF course that
> is not really as clean as I would like it to be but would work.
> 
> >
> > Not very clean though. Just an idea. My feeling is that the
> > requirement of keeping DESTROY out of RootI.pm calls for trouble.
> 

Ok, I have a better idea: In order to support multiple inheritance a
little bit more than Perl itself does, we equip RootI with a
cleanup-registration method, like _register_for_cleanup($method).
RootI also gets a DESTROY that calls all methods registered before:

sub DESTROY {
	my ($self) = shift;
	foreach my $method ($self-{'_cleanup_methods'}) {
		&($self->$method);
	}
}

In Root::IO::_io_initialization, the module registers its
_io_cleanup(), which is the same as DESTROY, just another name. So,
everytime IO.pm is used, regardless of position in inheritance, it's
cleanup code gets executed on object destruction. The only remaining
requirement is that DESTROY in a derived class chains back to
SUPER::DESTROY. But that's okay, we have the same in new().

In addition, much cleaner than trying by $self->can(), because a
module need not have knowledge about methods a derived object has.

If this makes sense to you, I'll implement it tonight. Honestly I
don't want to let 0.7 out with subtle requirements in place for the
sequence in class inheritance, and where you can have a DESTROY and
where not.

	Hilmar
-- 
-------------------------------------------------------------
Hilmar Lapp                            email: lapp@gnf.org
GNF, San Diego, Ca. 92121              phone: +1-858-812-1757
-------------------------------------------------------------