On Oct 20, 2004, at 6:18 PM, Miguel wrote:
Rene wrote:
I am pretty open about the name, but I think that the term Collection
does indeed capture what we have: (from the Java 2 API documention): "A
collection represents a group of objects, known as its elements." Which
is where we may end up down the line anyway.
If you worry about connotations in Java, then almost all names are out
since 'Set', 'Collection', 'List' are all taken :-).
Very true!
AtomSetCollection is what it will be.
Done.
2. The term 'index' has a special meaning. It means that it is *always*
zero-based and always runs through (atomSetCount - 1)
In the code you will see references to 'atomNumber' and references to 'atomIndex'. atomNumber is assigned by the underlying file type (like .pdb files). atomIndex is always zero based and always what we use.
I get it, a fine point but important. Thanks for pointing that out.
This will be important to remember as you work on some of the code.
I will make the change to the ModelAdapter interface.
Uhmm, the SmarterModelAdapter does not *implement* the ModelAdapter
*interface*, which brings up the question that I wondered about: Why is
ModelAdapter a class as opposed to an interface.
Ah yes ... a very good point.
It used to be an interface, but I changed it to a class at some point.
The reason was that the API was getting bigger and was changing as I added
support for new stuff.
As an interface, everyone who implements the interface had to change.
As a class, everyone who extended the class did not have to change ... they simply inherited the new functionality (which generally meant that there were class methods that returned null, Float.NaN, or Integer.MIN_VALUE)
Does it have anything do you have the Atom/Structure/Bond-Iterators as classes within the ModelAdapter? (If so why are they in the ModelAdapter.java file to begin with?).
I don't think so ... this was the same even when it was an interface.
I put those classes within the ModelAdapter because I wanted the entire API contained within the same file.
You are basically adding the method public String getAtomSetName(int atomSetIndex) { return "AtomSet "+atomSetIndex; } which I will override in the SmarterModelAdapter. At this point it wouldn't require anything besides that, and would not even enforce me to override it by not making it an abstract method. Right?
Exactly.
Since you said you'd work on the ModelAdapter, I did not do this one.
I also didn't get around to adding this method to the SmarterModelAdapter, but will do so soon (in the mean time the default implementation in the ModelAdapter should work fine). We'd actually have to come up with a way in which each reader can come up with a 'good' AtomSetName for each AtomSet. I guess the energy or vibrational frequency would be good starts for that.
Q: Do you know how to use fancy features of BBEdit to make this change
in
all the files in org/jmol/adapter/smarter ?
We seem to only be changing the Model.java to AtomSetCollection.java, and want to leave the ModelReader alone, right (even though this would really be an AtomSetCollectionReader, and most other things that refer to Model as a file...).
Correct.
And I think you are right that we should change from ModelReader to AtomSetCollectionReader.
Done. Which means I had to remove ModelReader.java and add AtomSetCollectionReader.java.
I noticed that there are still quite a few variables and classes that still have the name Model in them. I did not touch those...
But we have to change all the references to the Model class to AtomSetCollection.
Done.
And we need to change the variable name 'model' as well. I try to avoid
using abbreviations for variable names. But in this case we can use the
abbreviation 'asc'. We will use it consistently in all the Reader code and
then there will be no confusion when developers read the code.
I don't like abbreviations for variable names either, so I took the liberty to call the instances of AtomSetCollection atomSetCollection. I hope you don't mind.
A Multi-file Search and replace in the smarter directory for ' Model(' to ' AtomSetCollection' would do it,
Correct.
I just wanted to make sure that you didn't go through and manually do it
by hand :-)
besides the manual changes in the Model.java itself.
Correct.
I think that the SmarterModelAdapter would need some manual changes too.
Is that what you were asking?
I don't think that was what I was asking.
When I was asking about 'advanced features' of BBEdit I was really asking
about two things:
1. multi-file search & replace - DONE
2. have a very quick turn-around time for compiler errors.
Q: Can you launch 'ant' from within BBEdit and have it automatically take
you to the location of compiler errors?
I want you to try to make this change from Model model; to: AtomSetCollection asc;
I don't like
This should be a mechanical change, with no logic changes. So if you can
drive BBEdit it should go pretty fast.
Once it compiles, you need to figure out how to check it in. You are going
to add a new file (AtomSetCollection.java) ... and delete an old file
(Model.java)
Oops, I accidentally deleted the old file before I added the new one. But it caught it soon enough that the repository was without it for only a few minutes. I hope I didn't mess anybody up...
Ren�
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
