I am thinking that we should get all of these things as atom properties.
getAtomProperty(int atomIndex, String propertyName);
We can then pass in propertynames like "elementSymbol"
This would allow us to expand in the future.

Q: What do you think of this?

The (small) disadvantage I see is the the additional parsing that may need to be done when one needs the values not as strings.
For saving purposes that is not a problem, though.

There are some disadvantages of using this approach:

1.) what if some properties are integers and the others are floats, strings, ... ? You have to make unnecessary conversions.

One solutona to that is to use getIntAtomProperty, getStringAtomProperty, ... if you already want to use this.

2.) It calls for errors. There's a high probability someone will write "elementsymbol" od "elementSimbol" instead of "elementSymbol". It's a better idea to let the compiler decide whether the function call seems allright or not by defining a couple of constants:

static final short ELEMENT_SYMBOL = 1;
static final short ATOM_RADIUS    = 2;
...

and then call
    getFloatAtomProperty(atomIndex, ATOM_RADIUS);
    getStringAtomProperty(atomIndex, ELEMENT_SYMBOL);
instead.

Then it's also easier to implement the
    get...AtomProperty(int atomIndex, short propertyName)
with
    switch(propertyName) :
        case ATOM_RADIUS :
        case ELEMENT_SYMBOL :

which you can't do when using a string as input parameter.

However, I still think that writing 200 separate methods is still a better Idea (compiler checks for some errors) than writing everything in a single method (Eclipse is sometimes clever enough to write some of the methods automatically), but that's a matter of taste.

Mojca



-------------------------------------------------------
The SF.Net email is sponsored by: Beat the post-holiday blues
Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
_______________________________________________
Jmol-developers mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jmol-developers

Reply via email to