On Wed, Aug 3, 2011 at 4:31 PM, Nicolas Vervelle <nvervelle@gmail.com> 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 example with shapes, if you need to have a different base class for each possible shape, you simply can add an Class attribute in the enum : BALLS(0, "Balls", BallsBaseClass) and define a method getBaseClass() as a simple getter.

Careful on  that -- no class references outside their package, remember! But that's great, otherwise. I can think of all sorts of uses for Enum. 
 

Or for the example with axes mode, I see that in some classes you use a "switch (axesMode)" to choose a script command depending on the axesMode value : it could be replaced by adding this script command directly in the Enum and completely getting rid of the switch command.

Yes, very interesting.
 

I probably won't be able to work on Jmol in the next few days (lot of work and going abroad saturday for work for several weeks), so feel free to make changes, it won't collide with things I would do.


We need to coordinate with Jonathan. I'd prefer if you at least did the main changes. You have to do the changes manually, right? So something like SHAPES will be quite the overhaul. I want to be on vacation when you  do that! :)
Nico

On Wed, Aug 3, 2011 at 11:18 PM, Robert Hanson <hansonr@stolaf.edu> wrote:
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 association between names of shapes and such with their values. Something like

EnumShapes....

BALLS(0, "Balls")

EnumShapes.getShapeClassBase(EnumShapes.BALLS)

or such. My only concern is that we keep whatever efficiencies we have intact. No unnecessary for/while loops just to look something up, for example. That is, keep those static arrays.

I'm all for gutting JmolConstants and getting as much into Enum fields as we can.

We need to do this in a coordinated fashion, so let's confirm what you want to do when. I don't want to be in the middle of changes to a class and then have a clash on that, since this could be pretty major.

In terms of time frame, I'm all for doing this rapidly and getting it done, not slowly over weeks.

I think the CONTACT business is essentially done, so I'll be slowing down for a week or so.

Bob



On Wed, Aug 3, 2011 at 1:09 PM, Nicolas Vervelle <nvervelle@gmail.com> wrote:
I have just committed a simple example of using Enum on the axes mode :
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, Jonathan Gutow <gutow@uwosh.edu> wrote:
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, without have a good idea what they are called.  I think we just need to categorize them more carefully.

Jonathan
On Aug 2, 2011, at 1:03 PM, Nicolas Vervelle wrote:

> 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 proper Enum in its own file ?
> And then only using the Enums in the rest of the code.
> I think it will be cleaner and a lot better for type safety.
>
> Nico
> ------------------------------------------------------------------------------
> BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
> The must-attend event for mobile developers. Connect with experts.
> Get tools for creating Super Apps. See the latest technologies.
> Sessions, hands-on labs, demos & much more. Register early & save!
> http://p.sf.net/sfu/rim-blackberry-1
> _______________________________________________
> Jmol-developers mailing list
> Jmol-developers@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jmol-developers

                        Dr. Jonathan H. Gutow
Chemistry Department                                gutow@uwosh.edu
UW-Oshkosh                                          Office: 920-424-1326
800 Algoma Boulevard                                FAX:920-424-2042
Oshkosh, WI 54901
               http://www.uwosh.edu/facstaff/gutow


------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers


------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers




--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900

------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers



------------------------------------------------------------------------------
BlackBerry&reg; DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Jmol-developers mailing list
Jmol-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jmol-developers




--
Robert M. Hanson
Professor of Chemistry
St. Olaf College
1520 St. Olaf Ave.
Northfield, MN 55057
http://www.stolaf.edu/people/hansonr
phone: 507-786-3107


If nature does not answer first what we want,
it is better to take what answer we get.

-- Josiah Willard Gibbs, Lecture XXX, Monday, February 5, 1900