From: Miguel <mi...@jm...> - 2004-10-20 22:18:51
|
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): =22= A > collection represents a group of objects, known as its elements.=22 Whi= ch > 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=21 AtomSetCollection is what it will be. >> 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 adde= d 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) =7B > return =22AtomSet =22+atomSetIndex; > =7D > 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. >> 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. But we have to change all the references to the Model class to AtomSetCollection. 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 an= d then there will be no confusion when developers read the code. > 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; 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 goin= g to add a new file (AtomSetCollection.java) ... and delete an old file (Model.java) Use http://cvsbook.red-bean.com/cvsbook.html as a reference and figure ou= t how to do the stuff within BBEdit. Work with Tim Driscoll to resolve BBEdit issues. Miguel |