OK. We are on the same page then. :] Sorry for the long-winded e-mail.
SS On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote: > I assume you mean the revised version: > > Collection layers = argManager.getLayers(); > Object[] layersAsArray = layers.toArray(); > argList.setListData(layersAsArray); > > and not the original. Nothing wrong with that. > > Larry > > On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > So we don't have an issue with my using a utility method. That is good. > > > > What is horrible about my implementation? Can you please provide details? > > > > I know I am using two (2) more lines of code than your implementation > > would, but I tried to explain my reasons for this. I want to write > > rookie-friendly code, not super concise code. > > > > I realize my approach may be difficult for professional programmers to > > accept. My method may not always be the most "professional" but I > > think it is the most "understandable". > > > > Is there really something horrible about my implementation? Does it > > adversely affect the operation of OpenJUMP? > > > > I am eager to learn more. :] > > > > The Sunburned Surveyor > > > > Some of the goals I try to achieve in my open source programming are > > explained here: > > > > "http://www.literateprogramming.com/" > > > > A qoute from the website that sums it up for me: "Let us change our > > traditional attitude to the construction of programs: Instead of > > imagining that our main task is to instruct a computer what to do, let > > us concentrate rather on explaining to human beings what we want a > > computer to do." > > > > On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > OK, then: > > > > > > public static void setLayerNamesAsListData(LayerManager > > > argManager, JList argList) { > > > argList.setListData(argManager.getLayers().toArray()); > > > } > > > > > > I can cope with creating the utility method, just not the horrible > > > implementation. > > > > > > Larry > > > > > > On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > > Larry, > > > > > > > > Maybe I am totally missing something with my programming style. I will > > > > try to explain my reasoning for wanting this in a separate method, and > > > > then you can correct whatever bad programming habits that appear. :] > > > > > > > > First of all, I really try to avoid chaining method calls like you > > > > have done in your suggestion, especially in the argument list for a > > > > method. (I know experienced programmers are likely screaming at my > > > > stupidity at this point.) I do this because I believe it makes the > > > > code much more difficult to understand. I know it is more concise, and > > > > it may even be more efficient at run time, but these are not my first > > > > goals when I write source code for a program like OpenJUMP. (These > > > > chained method calls, which Jon loves, were one of my main obstacles > > > > to understanding JUMP's source code.) > > > > > > > > I really beleive the key to OpenJUMP's survival is not speed, > > > > efficiency, or even concise code. I beleive the key to OpenJUMP's > > > > survival is the ease with which OpenJUMP users and non-programmers can > > > > learn what is going on in the source code. We need to convert these > > > > users to programmers if we want to maintain a strong developer > > > > community. > > > > > > > > This effort to produce "understandable code" means that I try to use > > > > lots of source code comments, and I try to never chain method calls. > > > > > > > > As an example, what you wrote as: > > > > > > > > argList.setListData(argManager.getLayers().toArray()); > > > > > > > > I would write as: > > > > > > > > Collection layers = argManager.getLayers(); > > > > Object[] layersAsArray = layers.toArray(); > > > > argList.setListData(layersAsArray); > > > > > > > > Now, one reason I always look for room to create "utility methods" is > > > > so I can have concise code without the confusing side effects. So my > > > > three statements become: > > > > > > > > DialogUtil.setLayerNamesAsListData(); > > > > > > > > This allows me to be concise and the programmer reading my code can > > > > look at the setLayerNamesAsListData() method to understand my logic if > > > > he still needs to. It also allows me to add Javadoc comments to the > > > > method, which I wouldn't have been able to do if the logic was > > > > embedded in the class file. > > > > > > > > Here is another reason why I prefer a utility method for this scenario: > > > > > > > > What happens when we decide to modify the behavior of the getLayers() > > > > method? (Maybe we modify it to return an Iterator instance, or maybe > > > > we have it return an array directly.) I don't want to track down all > > > > of the instances of > > > > "argList.setListData(argManager.getLayers().toArray());" in all of my > > > > source code. With my technique I can just modify the > > > > DialogUtil.setLayerNamesAsListData(); method. > > > > > > > > I know this type of change isn't likely in OpenJUMP's source code, but > > > > I never know what changes future requirements or improvements might > > > > bring. Utility methods insulate my code from these types of changes by > > > > isolating the number of times I have to deal with them. > > > > > > > > It is important to remember that my point of view is somewhat skewed. > > > > I am not a professional programmer. I hadn't written one line of > > > > source code until I started using JUMP, and it is the only reason I > > > > learned Java. Even though I program for other reasons now, I always > > > > try to write my source code to be read and understood by someone just > > > > beginning to look "inside the box". > > > > > > > > The Sunburned Surveyor > > > > > > > > > > > > On 9/18/07, Larry Becker <[EMAIL PROTECTED]> wrote: > > > > > Why don't you just do: > > > > > > > > > > argList.setListData(argManager.getLayers().toArray()); > > > > > > > > > > and skip the whole method. > > > > > > > > > > Larry > > > > > > > > > > On 9/18/07, Sunburned Surveyor <[EMAIL PROTECTED]> wrote: > > > > > > I have attached my implementation of the setLayerNamesAsListData > > > > > > method. I was thinking about placing this method in Sigle's > > > > > > DialogUtil > > > > > > class. > > > > > > > > > > > > Someone asked to see my implementation, and I didn't want to cloud > > > > > > up > > > > > > the other thread, which has moved onto other topics. > > > > > > > > > > > > The Sunburned Surveyor > > > > > > > > > > > > P.S. - Did we decide if the DialogUtil class is the appropriate > > > > > > place, > > > > > > or should I put it into a separate JAR? > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > > > This SF.net email is sponsored by: Microsoft > > > > > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > > > _______________________________________________ > > > > > > Jump-pilot-devel mailing list > > > > > > Jump-pilot-devel@lists.sourceforge.net > > > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > http://amusingprogrammer.blogspot.com/ > > > > > > > > > > ------------------------------------------------------------------------- > > > > > This SF.net email is sponsored by: Microsoft > > > > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > > _______________________________________________ > > > > > Jump-pilot-devel mailing list > > > > > Jump-pilot-devel@lists.sourceforge.net > > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > > > > ------------------------------------------------------------------------- > > > > This SF.net email is sponsored by: Microsoft > > > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > > _______________________________________________ > > > > Jump-pilot-devel mailing list > > > > Jump-pilot-devel@lists.sourceforge.net > > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > > > > > > > -- > > > http://amusingprogrammer.blogspot.com/ > > > > > > ------------------------------------------------------------------------- > > > This SF.net email is sponsored by: Microsoft > > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > > _______________________________________________ > > > Jump-pilot-devel mailing list > > > Jump-pilot-devel@lists.sourceforge.net > > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > > > ------------------------------------------------------------------------- > > This SF.net email is sponsored by: Microsoft > > Defy all challenges. Microsoft(R) Visual Studio 2005. > > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > > _______________________________________________ > > Jump-pilot-devel mailing list > > Jump-pilot-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > > > > > -- > http://amusingprogrammer.blogspot.com/ > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Jump-pilot-devel mailing list > Jump-pilot-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel