On Jan 1, 2005, at 10:20 PM, Miguel wrote:
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.
So you basically suggest having get{type}AtomProperty with type={Int,Double,String}?
So for a more complex type of property one would have to get the String version and parse it yourself. Just the int and double version are automatically parsed.
That seems like a good idea to me, since it does not grow the number of methods too much and reduces unnecessary conversions for the most used types of data.
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.
This approach will work for the 'fixed' properties (i.e., the mapping of a field to a property) but not for more general types of meta data.
The way I view the problem is that we are looking for a method to associate both fixed data and flexible meta data with objects that the viewer deals with, i.e. itself, AtomSets and Atoms (Bonds, and other structural elements too? Not sure about that).
For the more restrictive input file formats (like xyz, and I believe hin and pdb too) the amount of properties an atom, or the model(s) as a whole are very limited (thus easily mapped onto fixed fields). When one parses an output file from a computational package, one may want to associate more meta data. I agree that for the atoms that would still be more limited than for a whole model, but you already have the case of several types of calculated charges for atoms (formal, Mulliken, electrostatic potential, and who knows what other methods come up with down the line:-).
A wild example for meta data for an atomset. Consider the case where one wants to retain MO information and build a viewer that will show MO levels and possibly show the MO coefficients when an MO is clicked, or even down the line show the MO as a surface in the JmolViewer wouldn't that be great?. For that one would need AtomSetProperties like:
MOEnergies : int nMO, double energy[n]
MOSymmetries : int nMO, String label[n]
MO{x} : int nAO, double coefficient[nAO]. Where x goes from 1-nMOor folded-in together:
MO{x} : double energy, String symmetry, int nAO, double coefficients[nAO]
or even more folded-in together:
MO : int nMO, (double energy, String symmetry, int nAO, double coefficients[nAO] )[nMO]
In order to make sense of the array of orbital coefficients: atomicOrbitals : int nAO, (int atomIndex, String orbital)[nAO]
and to be able to calculate the surfaces:
basisSets : int nb (int AOIndex, int nE (double coefficient, double exponent)[nE] )[nb]
or something like that....
I am not saying I would implement that, but the string argument version will allow one to be that flexible.
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.
In the kinds of projects that I have worked on I have generally found it
more flexible to reduce the number of methods.
As long as the methods themselves are flexible :-).
So where do we go from here?
I think we could do a combination:
1) have get/set{Object}{Field} methods for the {Field} of the {Object} that always exist (more direct and faster).
I realize that this could become a longish list.
The problem is if the input did not provide data for some of those fields, e.g., a vector or charge is not required for an atom...
In that case treating these as meta data (i.e., see point 2) could solve that problem, by returning a null (since it indeed is a property of the atom that is not defined.).
2) have set{Object}Property/get{Object}Property with String keys to deal with other meta data for {Object}
Both of these would have versions that have an int index for the {Object} that we have multiple of (Atom, AtomSet/Model).
Ren�
------------------------------------------------------- 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
