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

[Chris Mungall]

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)

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