[Bioperl-l] 0.7 release: Bio::Root::* classes

[Jason Stajich]

A consequence of going to RootI. 
Take a look at the following classes.

Bio::SeqFeature::Similarity -> ISA Bio::SeqFeature::FeaturePair -> ISA Bio::SeqFeature::Generic

We use the clever SUPER::_initialize(@args) to pass initialization
arguments up the hierarchy so that each can essentially obtain what they
need from args and a sub class can have additional arguments not supported
by the superclass.  To move to RootI each class will have its own new
function and will not call new on its superclass.   We could still 
create an initialize function that each class has and can call or else
a change at the top will require changing the subclasses.  

Comments on a better way to handle this?


On Mon, 13 Nov 2000, Jason Stajich wrote:

> On Mon, 13 Nov 2000, Ewan Birney wrote:
> 
> > On Mon, 13 Nov 2000, Hilmar Lapp wrote:
> > 
> > > Ewans proposal was to get rid of Bio::Root::Object.
> > > 
> > > Personally, I can't comment much on this subject. After looking at what
> > > Bio::Root::Object actually implements, it seems that everything I used so
> > > far (initialization, _rearrange(), throw(), warn()) in fact were things
> > > provided by Bio::Root::RootI.
> > 
> > This is why I made RootI (notice it doesn't give you the _initialize
> > routine, and there is still a dependency I belive on Root:;Objecct from
> > the warn method we need to remove).
> > 
> > I originally made RootI because there are a large number of cases where
> > you want to use the nice ->throw or ->warn syntax but don't want to have a
> > Root::Object (ie, a perl hash with particular properties) around. Classic
> > examples are C extension objects.
> > 
> > Having used RootI for a while, I can't imagine using anything from the 
> > Root::Object call. The only thing I have heard of being useful is hte
> > ->clone call. However, ->clone is a hard thing to implement once you are
> > outside the world of "well behaved" perl objects (eg, C objects, CORBA
> > stuff) and I don't think it is healthy to mandate that every bioperl
> > object should be "cloneable".
> 
> I think using RootI compliance is a very reasonable goal for 0.7 and
> volunteer to help on this front.  I think there may be some instances that
> require a bit of work, but will also help us really go through and look at
> every bioperl module before the release.
> 
> > 
> > 
> >  > 
> > > So, what are the arguments for abandoning Bio::Root::Object? Does anyone
> > > object to deprecate using it?
> > 
> > 
> > I don't ;)
> > 
> > Steve or Peter vh might do though....
> > 
> > 
> > > 
> > > 
> > > 	Hilmar
> > > 
> > > -- 
> > > -----------------------------------------------------------------
> > > Hilmar Lapp                                email: hlapp@gmx.net
> > > GNF, San Diego, Ca. 92122                  phone: +1 858 812 1757
> > > -----------------------------------------------------------------
> > > _______________________________________________
> > > Bioperl-l mailing list
> > > Bioperl-l@bioperl.org
> > > http://bioperl.org/mailman/listinfo/bioperl-l
> > > 
> > 
> > -----------------------------------------------------------------
> > Ewan Birney. Mobile: +44 (0)7970 151230, Work: +44 1223 494420
> > <birney@ebi.ac.uk>. 
> > -----------------------------------------------------------------
> > 
> > _______________________________________________
> > Bioperl-l mailing list
> > Bioperl-l@bioperl.org
> > http://bioperl.org/mailman/listinfo/bioperl-l
> > 
> 
> Jason Stajich
> jason@chg.mc.duke.edu
> http://galton.mc.duke.edu/~jason/
> (919)684-1806 (office) 
> (919)684-2275 (fax) 
> Center for Human Genetics - Duke University Medical Center
> http://wwwchg.mc.duke.edu/ 
> 
> 
> 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
> 

Jason Stajich
jason@chg.mc.duke.edu
http://galton.mc.duke.edu/~jason/
(919)684-1806 (office) 
(919)684-2275 (fax) 
Center for Human Genetics - Duke University Medical Center
http://wwwchg.mc.duke.edu/