From: Jules K. <jul...@go...> - 2010-10-21 10:34:28
|
After a good night's sleep over this issue, I indeed think refactoring Isotope to a field rather than a parent class is the best approach. As for Egon's suggested new interface: Shouldn't IElement be a part of IIsotope, rather than a seperate atom field? You seem to be suggesting atomA.setElement("Carbon"); atomA.setIsotope(13); which would by extent allow the faulty construct of atomA.setElement("Hydrogen") without touching the isotope/massnumber, resulting in a Hydrogen-13. I can easily imagine this happening, and it just seems wrong to me to allow this in the datamodel. Since mass number and Element are very intimately linked, I believe they should be one single class, with fields for element (=proton number) and isotope/mass number (=proton+neutron number, "mass number" is the preffered term). If I misunderstand and you plan to put element in the isotope class, it still shouldn't be duplicated in IAtom. Duplication of information allows for contradiction of information, and that should be avoided. As an added bonus, this allows us to keep track of properties that differ between isotopes of the same element, such as exact mass, boiling point, radioactive half-life etc. If you split isotopes in two classes (element and isotope), there's nowhere to put this stuff. Even if most of this stuff wouldn't even be put in until a future time, it's best to make a logical place now. To clarify: A massnumber of 14 could be any of beryllium, boron, carbon, nitrogen, oxygen or fluorine. Obviously it matters quite much which element it is. Likewise carbon could have any isotope number between 8 and 22. One property just doesn't mean much without the other, and only symbol means anything in isolation. This to me indicates they should both be in a class of their own. Of course, since many chemical applications couldn't care less about which specific mass-number we have ("it's a carbon, who cares if it's 14, 12 or 8?"), the massnumber should allow for Null/CDKConsts.undefined. It would then probably be clean to allow the symbol to be Null/CDKconsts.undefined as well, but I can't really think of a scenario where this would be needed (yet?). Additionally this allows us to build constructors that check if the values entered make sense, if I type in "new Isotope("H", 13)" it would be nice to get slapped on the wrist for making an impossible isotope. (Of course it may be nice to make an override contructor "Isotope(String symbol, Integer mass-number, boolean IKnowWhatImDoingOverride)" for when the CDK eventually gets adopted into the field of High-energy physics, where strange stuff like that could probably happen ;-) ) And a thought on internationalization: Should the Isotope class contain a field for "longName" in addition to its symbol? so "carbon" for "C", if yes, which language should this be? (As a Dutchie, i'd like "koolstof" better ;-) ) Or would this be better off with a lookup function elementSymbolToName(symbol, language)? I'm also pondering if the element-symbols should get their own enum. They are fairly rigid, but not completely immutable; new elements DO get discovered, and they are also renamed, Roentgenium used to be UnUnUniium before it was confirmed. Some sense-checking is required somewhere, but I guess this could also happen in the Isotope class setters/constructors. Singletons could still work, but then we would need a helluva lot of classes for every element-massnumber combination. class carbon8 extends isotope {..} class carbon9 extends isotope {..} .. class carbon22 extends isotope {..} That's 14 hard-coded classes just for carbon! What do you think? ~Jules On 20 October 2010 19:20, Egon Willighagen <ego...@gm...> wrote: > On Wed, Oct 20, 2010 at 3:01 PM, Jules Kerssemakers > <jul...@go...> wrote: >> The atoms in a molecule are all different atoms, but they can be of >> the same isotope, there is only one Isotope called Carbon-13, but any >> compound could contain multiple atoms of that. > > I would love to refactor the data model to have: > > interface IAtom { > > public getSet(IIsotope) > public getSet(IElement) > public getSet(IAtomType) > > } > > And quite like Rajarshi observed too, this will allow for the 119 (or > so) elements with symbols to be singletons, as well as the isotopes. > > This will involve a serious, major refactoring of a lot of code, and > we may need to schedule a week of hacking for that, with two or three > people working on it full time... > > Egon > > -- > Dr E.L. Willighagen > Postdoctoral Research Associate > University of Cambridge > 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 > > ------------------------------------------------------------------------------ > Nokia and AT&T present the 2010 Calling All Innovators-North America contest > Create new apps & games for the Nokia N8 for consumers in U.S. and Canada > $10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing > Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store > http://p.sf.net/sfu/nokia-dev2dev > _______________________________________________ > Cdk-devel mailing list > Cdk...@li... > https://lists.sourceforge.net/lists/listinfo/cdk-devel > |