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 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); > 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: [snip] >>> 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. 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
