Hi all, below is a suggested API extension that will make it possible to make immutable data classes within the CDK framework, *without* loosing compatibility with the current code base.
Advantages of immutable classes have been discussed on the list in the past, and two possible applications are discussed. The text is also available in the wiki, where everyone can add discussion too: http://wiki.cubic.uni-koeln.de/cdkwiki/doku.php?id=immutableinterfaces Regards, Egon ================================================================== ====== Immutable Data Classes ====== Some CDK users have expressed in the past their wish for immutable data classes. A step towards this would be a separation of 'immutable' and 'mutable' interfaces for our data classes. For example, this would mean that the IAtom interface would split up into interface IImmutableAtom {} and interface IAtom extends IImmutableAtom {} All set() methods would stay in the IAtom interface, while all get methods would move to the IImmutableAtom interfaces. It is important to note that the suggested IAtom interface is **identical** to the current interface, this suggestion just increases possibilities, and is fully backwards compatible with the current code base. = Application 1: immutable data classes = The above changes would allow making immutable data classes within the CDK, making compatibility with, for example, Octet. Immutable data classes would not require an infrastructure for notifications, allowing more flexibility when using the CDK. Similarly to the interfaces, the setup would be like: class ImmutableAtom implements IImmutableAtom {} and class Atom implements IAtom {} It would be nice to be able to have this Atom extend Immutable atom, but it already needs to extend Isotope. Extending from two classes is not possible in Java; this problem occurs with the debug and nonotify data classes too. = Application 2: algorithms that modify objects, and those that do not = While application 1 is more difficult to realize, the split up of these interfaces has the advantage that implementation of algorithms in the CDK can explicitely use the immutable interface instead of the current mutable one. This ensures that the algorithm itself will not touch the molecule. However, since this is optional, and the IAtom interfaces is identical to the current IAtom interface, **no** modifications in the CDK need to be made by default. ================================================================== -- CUBIC blog: http://chem-bla-ics.blogspot.com/ ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Cdk-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/cdk-user
