On Jan 2, 2005, at 12:02 PM, Miguel wrote:
Rene wrote: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}?
Yes
Float instead of Double Plus Boolean
So for a more complex type of property one would have to get the String
version and parse it yourself.
No.
The default type getAtomProperty would return a java.lang.Object
Hadn't thought of that. Good idea.
This would allow the return of more complex data structures.
Object getAtomProperty(int atomIndex, String atomProperty); int getIntAtomProperty(int atomIndex, String atomProperty); boolean getBooleanAtomProperty(int atomIndex, String atomProperty); String getStringAtomProperty(int atomIndex, String atomProperty);
Besides the Float one, would we also have similar ones for the AtomSet properties?
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.
[snip]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: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).
Agreed.
I would rather have an API that supported more flexible data properties in
the future.
So where do we go from here?
I am not comfortable introducing a large number of very specific methods
into the core of the Viewer.
As things currently stand, the core viewer code does not know very much
about the implementation of the individual 'shapes' that exist. That level
of abstraction is a good thing, reducing system complexity.
My current thinking is this:
I plan to implement it with String property names. The Strings that get
passed in must be string constant (or interned). System efficiency is not
an issue in this part of the system.
Great.
I assume that this also means that the readers will need to be adjusted to add the vectors, and charges as an AtomProperty, in addition to the current way of adding them?
If some people would feel better using individual methods and having the
compiler provide some validation then we can consider writing another
package that provides wrappers around individual functions to provide this
'protection'.
Miguel
------------------------------------------------------- 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
------------------------------------------------------- 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
