Re: [Cdk-devel] refactoring descriptor interfaces

[Rajarshi G. <raj...@gm...>]

I agree that this is not too different from what is already there; and
in addition, we loose some compile time checks similar to the way we
would loose them in the second option I described above (ie
implementor decides what to do with the calculate from IDescriptor
rather than being mandated by the API). If this approach is
acceptable, we might as well go to the single interface design and let
implementers deal with the varargs.

On Mon, Dec 12, 2011 at 2:37 AM, Nina Jeliazkova
<jel...@gm...> wrote:
>
>
> On 12 December 2011 08:07, Egon Willighagen <ego...@gm...>
> wrote:
>>
>> On Sun, Dec 11, 2011 at 8:03 PM, Rajarshi Guha <raj...@gm...>
>> wrote:
>> > The alternative approach that we were bouncing aorund was to simplify
>> > this hierarchy and genericify the IDescriptor interface,
>> > IDescriptor<T>. Then any descriptor implementation would specify the
>> > appropriate T. So a molecule descriptor would be refactored as
>> >
>> > ANewMolDesc implements IDescriptor<IAtomContainer>
>> >
>> > Now, this approach would require that IDescriptor itself now provides
>> > the calculate(T) method. But as note above, different descriptor types
>> > require different types of calculate methods (differeing in number and
>> > types of arguments). So one solution is to have IDescriptor provide
>> > calculate(T, ...) - ie use varargs and so the implementing class will
>> > perform the check for number and type of varargs.
>>
>> An intermediate option would be to reduce the set to two interfaces,
>> one with each of:
>>
>> calculate(IAtomContainer) allowing "implements IMolcularDescriptor"
>> calculate(S,IAtomContainer) sllowing "implements IPartDescriptor<S>"
>>
>> where S is in IAtom, IBond ... and, well. IAtomPair, an interface we
>> currently do not have...
>>
>> > This approach flattens the hierarchy, but now removes compile time
>> > checks,
>>
>> Indeed, because the API no longer hard-code what arguments are
>> exception, which sort of counters the introduction of generics...
>>
>> > at least for atomic and bond descriptors. (I'm not sure
>> > whether we can also identify molecular descriptors via reflection in
>> > this case)
>>
>> The downside of the above solution is that the hierarchy is not that
>> much flattened...
>>
>> Can someone come up with an idea that would remove IFooDescriptor, to
>> be replaced with IDescriptor<T,S> where S is optional, for the whole
>> molecule case...?
>>
>
> What about two interfaces:
>
> for molecular descriptors
>
> interface IDescriptor<T extends IChemObject> {
>    calculate(T t) ;
> }
>
> for atom/bond/etc
>
> interface IPartialDescriptor<T extends IChemObject> extends
> IDescriptor<IAtomContainer> {
>          calculate(IAtomContainer a,T parts) ;
> // or
>          calculate(IAtomContainer a,T... parts) ;
> }
>
> and e.g. atomic descriptors will implement interface
> IPartialDescriptor<IAtom> .
>
> The classes implementing the later will have two calculate methods, one
> derived from IDescriptor and one from IPartialDescriptor.
> The one with single argument for calculate() could be used to calculate
> descriptors for e.g. all atoms or bonds, or just throw an exception, if not
> applicable.
>
> Not sure if this suggestion answers the question, it is not very far from
> what is implemented currently.
>
> Nina
>
>> Egon
>>
>> --
>> Dr E.L. Willighagen
>> Postdoctoral Researcher
>> Institutet för miljömedicin
>> Karolinska Institutet (http://ki.se/imm)
>> Homepage: http://egonw.github.com/
>> LinkedIn: http://se.linkedin.com/in/egonw
>> Blog: http://chem-bla-ics.blogspot.com/
>> PubList: http://www.citeulike.org/user/egonw/tag/papers
>>
>>
>> ------------------------------------------------------------------------------
>> Learn Windows Azure Live!  Tuesday, Dec 13, 2011
>> Microsoft is holding a special Learn Windows Azure training event for
>> developers. It will provide a great way to learn Windows Azure and what it
>> provides. You can attend the event by watching it streamed LIVE online.
>> Learn more at http://p.sf.net/sfu/ms-windowsazure
>> _______________________________________________
>> Cdk-devel mailing list
>> Cdk...@li...
>> https://lists.sourceforge.net/lists/listinfo/cdk-devel
>
>



-- 
Rajarshi Guha
NIH Chemical Genomics Center