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

[Chris Mungall]

Hi Kris

The object model design looks very sound. However, I noticed that there
are cycles in the object graph (eg bidirectional links between Atom and
Residue).

This causes problems for perl, as the garbage collector gets confused
about reference counts and won't clean up properly. (IMHO this is part of
a larger problem with object oriented design as a whole, as attributes
aren't first class entities in their own right)

This won't be a problem for reading in a few PDB records, but, say,
cycling through all of PDB will cause your memory usage to go up and up. I
learned this lesson the hard way with my first perl object model, after
doing java object models, it was a painful business going back and
refactoring the code :@(

One way around this is to keep your own reference counts override the
DESTROY method to make sure everything is cleared - this can be tricky.

Another way would be to have everything go through a singleton
ProteinData object which would hold all parent/child relationships. The
Residue/Atom object would be unaware of their reciprocal links, the client
code would have to ask the ProteinData object for this.

I notice you haven't checked in your StructureI object yet, so I can't run
the tests - I may be missing something

Cheers,
Chris

On Fri, 16 Nov 2001, Kris Boulez wrote:

> I've just commited the first version of the Bio::Structure objects (and
> tests in t/Structure.t). This is a first version (so please handle with
> care). The objects are organized in a tree like manner, where each
> level consist of one or more objects of the next level.
> 
>  Bio::Structure::Entry
>  		 Model
> 		 Chain
> 		 Residue
> 		 Atom
> 
> Each object should know who his parent/children are. Some basic methods
> are provided (more to follow).
> 
> As it is, interface definitions are not (yet) used. Question for the
> design gurus on this list: do I need an entry in an I file per public
> method and do I need an I file for every module ?
> Other question: is it better to split out tests per module or to have
> one big test for all the Structure modules (69 tests now).
> 
> I'll now focus on Bio::Structure::IO and see how much there is with
> Bio::SeqIO and see which methods ev. can go in a common module.
> 
> 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
>