[Bioperl-l] First commit of Bio::Structure objects

Ewan Birney birney@ebi.ac.uk
Mon, 19 Nov 2001 18:56:48 +0000 (GMT)


On Mon, 19 Nov 2001, Chris Mungall wrote:

> 
> Hmm, it's still a pain to have the user explictly clear up objects, a
> factory would help but I'm not sure it's really the bioperl way.
> 
> What about my other solution, have a Protein object, the protein stores a
> graph of all parent child relationships, so the ProteinComponent objects
> know nothing of their parents/children.
> 
> ie instead of 
> 
> $atom->get_residue()
> $residue->get_atoms()
> 
> you would so 
> 
> $protein->get_residue($atom)
> $protein->get_atom($residue)
> 

I'd make this perhaps part of the Entry object.

> This is effectively the same as Ewan's solution, it's just that you give
> the scriptwriters a hand with the bookkeeping, inside the protein object.
> The user could eschew the protein object and do their own bookkeeping via
> ids.

I do think this is the best way to do this. Also it makes the "data
model" objects nice and clean, except for Entry which has to hold indexes
for all its subcomponents, but as entry is the grandparent of everything,
this works out fine.


This is almost classic design pattern called something like.... protected
graph. Not sure what it is called. I've seen it before...

( The real classic allows the move $atom->get_Residue by having "weak"
links between the sub components of the graph. The holder object (Entry in
our case) DESTROYs all the sub components when the entry object is
removed. This could actually be possible inside this but would be fiddly
to implement right - you would have to be *very* certain about the
detachment of references correctly inside the graph).



> 
> there could either be one protein object per protein, or a singleton
> object that stores all protein component graphs (the latter would be
> useful if anyone ever wanted to add protein-protein interaction stuff to
> bioperl)
> 
> (We could even use the same framework as the generic extensible annotation
> system)
> 
> > I'll implement the second one, unless someone starts shouting.
> 
> SHOUT!
> 
> > Kris,  
> > -- 
> > Kris Boulez 				Tel: +32-9-241.11.00
> > AlgoNomics NV 				Fax: +32-9-241.11.02
> > Technologiepark 4 			email: kris.boulez@algonomics.com
> > B 9052 Zwijnaarde 			http://www.algonomics.com/
> > 
> 
>