How about:
sub _cleanup_methods {
warn "please use Bio::Root::Root, not Bio::Root::RootI";
}
I'll put these two things in, if there's no more debate.
Lincoln
On Monday 10 December 2001 22:46, Jason Stajich wrote:
> We need to also do something about the calling of _cleanup_methods as this
> will currently cause DESTROY to segfault if one does not reimplement
> _cleanup_methods in the subclass - I don't see any reason that
> _cleanup_methods has to DO anything unless someone wants to add methods to
> it. Right now someone extending the RootI interface, and providing their
> own new method will get a perl segfault when the object is DESTROYED. If
> _cleanup_methods doesn't return anything, nothing is harmed, someone must
> call _register_for_cleanup to add a method and if this isn't implemented
> then the developer will get some errors.
>
> Can I suggest additionally doing:
> sub _cleanup_methods { # purposely an empty method
> }
>
> Rather than an _abstractDeath('_cleanup_methods') here.
>
> Is everyone happy with the Root::IO way of doing tempfiles/catfile? I
> think it is nice to provide a little backwards compatibility, but it seems
> like File::Spec is pretty standard - although some versions have
> different #'s of methods. Additionally we should insure that File::Temp
> tempfiles can be cleaned up on object destruction not just when the Perl
> script exits memory. If someone wanted to take some time to test all the
> cases - would be awesome.
>
> Has anyone looked at Damian's new NEXT module? Nice little post about
> this on use.perl.org. Looks like a nice way to do method dispatch and we
> might want to consider adopting it ... Later, I know! Lincoln has also
> suggested starting to use some perl 5.6 niceties: 'use base' and others.
> I know that Sanger system perl version and the rest of our users has been
> one of the things stopping us, but I would like to consider some of these
> new features in the post 1.0 era (getting ahead of myself as ususal).
>
> -jason
>
> On Sun, 9 Dec 2001, Lincoln Stein wrote:
> > I would suggest putting this in Bio::Root::RootI
> >
> > sub new {
> > local($^W) = 0;
> > my ($caller, @args) = @_;
> >
> > my $self = $caller->_create_object(@args);
> >
> > my %param = @args;
> > my $verbose = $param{'-VERBOSE'} || $param{'-verbose'};
> >
> > ## See "Comments" above regarding use of _rearrange().
> > $self->verbose($verbose);
> >
> > return $self;
> > }
> >
> > sub _create_object {
> > my $class = shift;
> > warn "Attempt to use deprecated API: Please use Bio::Root::Root
> > instead"; require Bio::Root::Root;
> > return Bio::Root::Root->new(@_);
> > }
> >
> > This way, if they try to create a new Bio::Root::RootI object, they get a
> > Bio::Root::Root (and a deprecation warning) instead.
> >
> > Lincoln
> >
> > On Sunday 09 December 2001 14:54, Ewan Birney wrote:
> > > I basically like the split of Bio::Root::RootI interface away
> > > from implementation, but it does give us a backward compatibility
> > > problem.
> > >
> > >
> > > Some (external) modules written using Bioperl - in particular large
> > > tracks of Ensembl (say - 50 modules) - now break as they assumme that
> > > Bio::Root::RootI new works.
> > >
> > >
> > > There is alot of active ensembl's out there with the current code base,
> > > and we are not going to be able to change these code bases (they are
> > > off the stable branch of ensembl) by Janurary.
> > >
> > >
> > > What I would like to do is reintroduce a new function to RootI (blesses
> > > an anonymous hash) with a strong "deprecated" warning being thrown.
> > >
> > >
> > >
> > > Jason/Lincoln/anyone else - do you think this ok?
> > >
> > >
> > >
> > >
> > > ewan
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
--
========================================================================
Lincoln D. Stein Cold Spring Harbor Laboratory
lstein@cshl.org Cold Spring Harbor, NY
NOW HIRING BIOINFORMATICS POSTDOCTORAL FELLOWS AND PROGRAMMERS.
PLEASE WRITE FOR DETAILS.
========================================================================