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

[Jason Stajich]

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

-- 
Jason Stajich
Duke University
jason@cgt.mc.duke.edu