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

[Corradi, John]

> -----Original Message-----
> From: Chris Mungall [mailto:cjm@fruitfly.bdgp.berkeley.edu]
> Sent: Monday, November 19, 2001 1:47 PM
> To: Kris Boulez
> Cc: Ewan Birney; Bioperl mailing list
> Subject: Re: [Bioperl-l] First commit of Bio::Structure objects
> 
> 
> 
> 
> On Mon, 19 Nov 2001, Kris Boulez wrote:
> 
> > Quoting Ewan Birney (birney@ebi.ac.uk):
> > > 
> > > Re: objct cycles - the DESTORY route is really hard to 
> get right so I
> > > would encourage you Kris to go for the "parent object 
> knows about the
> > > relationships" or (my solution) - punt on making children 
> know about the
> > > parents, and force any script that wants to know about 
> this to do its own
> > > bookeeping ...
> > > 
> > After a weekend of thinking about it, I think I understand 
> the problem
> > and I agree that the only solution there is now (client 
> needs to call
> > DESTROY method on object), will not work.
> > > 
> > > Most scripts probably wont need to go child--> parent as 
> to get to the
> > > child they must have gone through the parent...
> > > 
> > Unfortunately I think they do. A typical use case would be 
> "Give me all
> > the atoms which are less then 5 A away from this atom". 
> Starting from
> > this list of atoms you would then want to know to which 
> resideu/chain
> > they belong.
> > 
> >    $atom->residue->id
> > 
> > I see two possible solutions for this:
> > 
> > - store the residue/chain info as textual attributes when
> >   creating/modifying the Atom (if we do this why do we need 
> objects and
> >   references)
> > - use an extra layer on top (as suggested by Chris 
> Mungall), which is
> >   called 'Factory' in Design Patterns-speak (I think).
> 
> 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)
> 
> 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.
> 
> 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)

I'm coming into this late and I don't know all the specific issues relevant
to this model.  However, Chris' suggestion is the route we took when we
implemented a Gene Ontology browser at Jax.  A graph object keeps track of
nodes and edges so the nodes don't need to know about their parents or
children.  Likewise, the graph doesn't need to know much about the nodes
(perhaps only that a node has a unique id).  Don't know if ours was the
cleanest design, but it avoids the bidirectional links that are making heads
hurt.

> 
> (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/
> > 
> 
> _______________________________________________
> Bioperl-l mailing list
> Bioperl-l@bioperl.org
> http://bioperl.org/mailman/listinfo/bioperl-l
>