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

Ewan Birney birney@ebi.ac.uk
Mon, 13 Nov 2000 10:06:20 +0000 (GMT)


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


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