[Bioperl-l] Backward compatibility mode for Bio::Root::RootI

[Ewan Birney]

On Tue, 11 Dec 2001, Lincoln Stein wrote:

> 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.

Great - does this mean putting in the new() workaround as well?



> 
> 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
> 
>