[octet-devel] Re: [QSAR-devel] PropertyAcceptor

[Joerg K. W. <we...@in...>]

Hi Rich,

> What if, instead, my TPSACalculator simply maintained a boolean array called sp2nitrogen with a size equal to the number of atoms in a given molecule.
> My calculator would simply iterate over all Atoms int the Molecule checking for sp2 nitrogen. When one is found, lets say at index n, sp2nitrogen[n] is set to true. At the end of this process I have a boolean array whose elements tell me the indicies of the sp2-nitrogen atoms in the Molecule. Is this not the same result as Atom inheriting the PropertyAcceptor interface and using atom.setProperty()?
I think there is also a pattern for this array-access via index and 
wrapping in an object Simple... i can't remember the name.
But i agree completely that we should have the ability to use arrays 
here (SparseWrapper ?).
Sure you can produce the same result with a meta-layer, e.g. as in JOELib.
Store array in molecule getProperty(SP2ArrayKey).get(atomIndex), so it's 
just a question of the design you're more experienced with
The most thing i'm insterested in is to provide the interface with an 
ability to access propertys also in a common way, i don't care which 
way, so feel free to suggest another approach.

> So, the approach I'm suggesting is to rigorously separate data storage from model-level interface definition.
Amazing ... simplicity, complexity-if-you-want and speed ... all in one 
... sounds fantastic !
So change these things !!!

Kind regards, Joerg

> Another, more integrated, approach would be to use the Decorator Pattern (see: http://c2.com/cgi/wiki?DecoratorPattern).
> Structure (http://structure.sourceforge.net) uses this approach to associate 2-D atom coordinates with Atoms. In a nutshell,
> - net.sourceforge.octet.extension.MoleculeDecorator is a concrete convenience class that implements the Molecule interface by passing all method calls through to a private instance of the Molecule it decorates.
> - net.sourceforge.structure.molecule.BasicMolecule2D extends MoleculeDecorator, adding methods for 2-D coordinate manipulation.
>  
> Clients then go:
>  
> Molecule mol = ...; // get the molecule from somewhere
> Molecule2D mol2d = new Molecule2D(mol);
> mol2d.move(mol2d.getAtom(0), 0.0, 0.0);
>  
> // etc...
>  
> Getting back to octetInterface... If we absolutely need to have a Molecule that can store properties, how about defining a class like:
>  
> public class PropertyMolecule extends net.sourceforge.octet.extensions.MoleculeDecorator
>   implements PropertyAcceptor
> {
>   // implement the PropertyAcceptor interface
> }
>  
> (Aside: Maybe a set of methods like PropertyAcceptor.setProperty(Atom atom, PropertyKey key) would be useful here. Also, to avoid the defensive copy situation above, PropertyAcceptor could then define PropertyAcceptor.addPropertiesListener()).
>  
> Now this frees implementors of the Molecule interface from having to support the PropertiesAcceptor interface. It also fosters a "pay-as-you-go" approach to interface complexity and overhead. If a client needs this functionality, then they have to pay for it, but we don't compel clients to pay for what they don't need. We can get ease of use, simplicity, and high performance at the same time.
>  
> cheers,
> rich
> 
> "Joerg K. Wegner" <we...@in...> wrote:
> Hi all,
> 
> so here is the first version, of the 'combined' octet interface:
> (ups, our server seems to be down, please try again in a few hours)
> http://www-ra.informatik.uni-tuebingen.de/mitarb/wegner/tmp/octet/octetInterface.zip
> 
> TECHNICAL:
> It has the following structure:
> cdk
> joelib
> octet
> octet4CDK
> octet4JOELib
> octetImplementations
> 
> CDK, JOELib, Octet should work on their own via 'ant compile'
> 
> octet4CDK,octet4JOELib requires Octet/CDK or Octet/JOELib they catch on 
> their own
> 
> octetImplementations Octet/CDK/JOELib and contains new implementations 
> for Octet. So this part of the project combines all efforts !!!
> 
> DESIGN:
> I've added to octet/properties
> AssignmentFactory.java
> DataFactory.java
> Property.java
> PropertyAcceptor.java
> PropertyKey.java
> PropertyKeyFactory.java
> PropertyKeySet.java
> PropertySet.java
> PropertyVersion.java
> 
> So all objects which can accept properties can extend PropertyAcceptor. 
> I've added them to Atom and Molecule, so the CDK interface will not work 
> any more, also the basic implementations which are part of 
> octetImplementations (i've moved them from octet).
> The octet4JOELib part contains until now no functionality.
> I will also add/change the substructure parts to Octet, but not this 
> week :-)
> 
> So, Rich AND Egon, if you agree to this structure, then we should add 
> this first version to Octet-CVS, otherwise change all things you like 
> and send me a link to download the changed version.
> (I hate CVS and it's directory problem)
> 
> Please read the API docu, so i must not explain things twice in this 
> e-mail, please complain anything you do not like in the actual design. 
> I've used a really widely usable Object storing mechanism, and are 
> forcing property-version methods. Also we should remove things like in Atom:
> countElectrons
> getLabel
> Because this are simply two Property's for an Atom, so we are working on 
> attributed molecular graphs. To get the values, these definitions should 
> be part of the
> PropertyKeyFactory
> adding methods, like
> public PropertyKey getElectronsKey();
> public PropertyKey getAtomLabelKey(); // what's meant by label, isn't 
> 
> // this is too general here?
> 
> Kind regads, Joerg
> 


-- 
Dipl. Chem. Joerg K. Wegner
Center of Bioinformatics Tuebingen (ZBIT)
Department of Computer Architecture
Univ. Tuebingen, Sand 1, D-72076 Tuebingen, Germany
Phone: (+49/0) 7071 29 78970
Fax: (+49/0) 7071 29 5091
E-Mail: mailto:we...@in...
WWW:    http://www-ra.informatik.uni-tuebingen.de
--
Never mistake motion for action.
                                     (E. Hemingway)

Never mistake action for meaningful action.
                                (Hugo Kubinyi,2004)