From: Rajarshi G. <raj...@gm...> - 2011-11-08 14:43:53
|
On Tue, Nov 8, 2011 at 3:28 AM, Egon Willighagen <ego...@gm...> wrote: > This has been discussed a couple of times already, Heh, indeed :) > Keeping track of modifications > > Option 1: the cheap way > > Have a get/setIsModified(bool), which gets updated by all methods that > change the structure, like addAtom(), removeBond(), etc. Yes, the easy way; but will be tricky to ensure that we have caught all possible places where a change may occur > Option 2: the immutable pattern This is nice, but it seems it has two issues: * if we go for immutable objects, pretty much all core classes need to become immutable. Otherwise, from a library user point of view, it will be a pain to keep track of what is immutable and what is not. So it's pretty much all immutable or not * as far as I can tell it does not address the issue of whether an algorithm (say aromaticity) needs to be run or not. Sure, once a molecule is constructed it does not change. Removing a bond, would lead to a new molecule being constructed. But it would still need some flag to indicate that aromaticity perception needs to be rerun > The Cache: > > The second design decision that needs to be made is where to put the > cache. Some discussion here is appreciated too. One option is to just > use the IChemObject.properties... A second option is to use an > external, possible global cache. How would a global cache help here? Shouldn't the cache be local to a molecule (to address the issue of whether a molecule has become 'dirty' or not)? Or are you talking about a pool of core class instances? -- Rajarshi Guha NIH Chemical Genomics Center |