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

Reply via email to