On Sun, Aug 7, 2011 at 3:59 AM, Nicolas Vervelle wrote:
> Hi Bob,
>
> I am not sure that we need to specify explicit values for ids for Enum
> (even if we need ids outside the enum).
>
> There are many things that can be done properly with Enums.
> For example, the ordinal() method should return a
Hi Bob,
I am not sure that we need to specify explicit values for ids for Enum (even
if we need ids outside the enum).
There are many things that can be done properly with Enums.
For example, the ordinal() method should return an automatic numeric
identifier for each instance (it starts at 0 for
I took a whack at this and found one bug even. Hopefully introduced no more.
But it does feel right. There are some instances, such as with the axesMode
and with proteinStructure where we need to have an integer ID still and
refer to that because that is documented as being exposed.
Very interest
On Wed, Aug 3, 2011 at 11:43 PM, Robert Hanson wrote:
>
>
> On Wed, Aug 3, 2011 at 4:31 PM, Nicolas Vervelle wrote:
>
>> Hi Bob,
>>
>> I agree about putting the constants in a new package, a little preference
>> for org.jmol.constants (we may have other things than enum).
>>
>> Enum can be as com
On Wed, Aug 3, 2011 at 4:31 PM, Nicolas Vervelle wrote:
> Hi Bob,
>
> I agree about putting the constants in a new package, a little preference
> for org.jmol.constants (we may have other things than enum).
>
> Enum can be as complex as you like, for example having many attributes.
> For the examp
Hi Bob,
I agree about putting the constants in a new package, a little preference
for org.jmol.constants (we may have other things than enum).
Enum can be as complex as you like, for example having many attributes.
For the example with shapes, if you need to have a different base class for
each p
Very nice. I didn't know about Enum for Java, but that would close a bit of
a management problem.
I suggest:
1) making a new package for constants. It's never made any sense to have
these in org.jmol.viewer. So I suggest
org.jmol.enum
or
org.jmol.constants
2) building into that the associati
I have just committed a simple example of using Enum on the axes mode :
- Revision 15918 in SVN
- Changes
http://bazaar.launchpad.net/~nvervelle/jmol/trunk/revision/11402
If this seems ok, I can try to apply the same principle on other constants.
Nico
On Wed, Aug 3, 2011 at 2:50 AM, Jo
This sounds like a good idea. I would really like to see a way of making this
clearer to read for future programmers as well. If this is going to undergo a
major refactoring we should put some thought into organizing the constants in a
way that makes it easy to find those you are interested in
Hi,
Looking at JmolConstants, I think we could refactor it to have much cleaner
code in Jmol.
I think especially about the list of constants.
Since we are now using Java 5 code, what do you think about using Enum ?
For example, replacing all the CALLBACK_xxx constants and callbackNames[] by
an pr
10 matches
Mail list logo
