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
