Re: [Cdk-devel] Documentation or code enforcement of preconditions

[Egon W. <ego...@gm...>]

On Fri, Dec 19, 2008 at 8:59 PM, Rajarshi Guha <rg...@in...> wrote:
> On Dec 19, 2008, at 2:49 PM, Egon Willighagen wrote:
>> Control, performance, IIRC.
>
> Aaah. I'd say that input checking is different from input processing.
> In the sense that, IMO, code should check that the input has what
> they need. If not, throw an exception etc, but not necessarily
> actually do the pre-processing job itself

<snip>

>> If the interfaces had a clear separation of mutable and immutable data
>> models, keeping track of what has already been calculated... and then
>> methods like the LPChecker can decide itself when they have to (re)do
>> some precalculation...
>
> I see. What about the idea of flags? It would require quite a degree
> of manual examination to decide when and under what conditions a flag
> needs to be of or on - but would be good for such preconditioning and
> wouldn't be a big performance hit

I agree that prechecking is not the same as preprocessing... but I do
suspect there is a lot of overlap... unless you have a very strict
flag invalidation system... otherwise, deciding if atom and bond ring
flags are still valid just require a recalculation...

We could experiment with with having methods like addAtom() invalidate
flags and sorts...

In particular when the new unit testing system for the data classes is
online (data, datadebug and nonotify)...

Egon

-- 
----
http://chem-bla-ics.blogspot.com/