Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #11566

Re: Blocks for scope control

Show all headers | View raw

On 12-01-21 08:25 AM, Robert Klemme wrote:
> On 20.01.2012 02:16, Arved Sandstrom wrote:
>> On 12-01-16 02:55 AM, Robert Klemme wrote:
>>> On 15.01.2012 22:49, Arved Sandstrom wrote:
>> [ SNIP ]
>>
>>> Regarding the method refactoring argument: if there is so much code and
>>> hence so many local variables that you want to use blocks to introduce
>>> smaller scopes chances are that the logic within that blocks is also
>>> largely independent from the code around so it is a good candidate for
>>> refactoring anyway.  The reason for refactoring into methods isn't the
>>> scope but the independent logic.
> 
>> Let me give you an example. Some days prior to writing my post I had to
>> write some code that processed a number of items in a similar fashion.
>> Each item was a matter of 2 or 3 lines of code. In theory each process
>> could have been collapsed into one very long line with multiple
>> duplicated and chained method calls, rather than use temporary local
>> variables, but I abhor this practice. So for clarity I kept the
>> operations on each item as 2 or 3 lines of code with at least one
>> temporary local variable.
>>
>> Although the type of the local variable was the same, the operations
>> that produced it were not - they depended on the item. So any method
>> that would have replaced all these individually simple simple groups of
>> operations would have been either a moderately complex switch or a
>> moderately complex if-else if-else structure, less easy to understand,
>> and more error-prone. Furthermore, a flag would have been necessary to
>> the method to indicate which branch to take.
> 
> Why _one_ method?  There could be a method for each variant, couldn't
> it?  Chances are that the same code could be used for several items so
> you end up with less methods than items.

There could be, sure. I'll discuss that below your second comment.

>> As you may have guessed this logic had to do with post-processing
>> various String and Boolean command-line options delivered by a
>> command-line processor. Quite frankly there is nothing pretty about
>> this, and there never has been in any language I've ever used - all you
>> can hope for is to keep the code clear, as error-free as possible, as
>> change-proof as possible (one of the main reasons for me using local
>> blocks actually), and just tolerate the boilerplate processing otherwise.
> 
> I agree that this boilerplate is tedious, regardless how you do it.  But
> I didn't guess that your description was about such a scenario. ;-)
[ SNIP ]

There are a number of Java command line option parsers available; I
happen to like JArgs which is GNU getopt compatible.

Your first step after defining your options and running the parser on
actual arguments is to retrieve raw option values. JArgs is not generic,
so the retrieved option values are retrieved as Objects although they
are actually Strings or Booleans or Doubles or Integers or Longs.
Depending on how many of these types are in use in your situation, if
you were going to have convenience methods at all you'd have one for
each datatype involved in your options.

Many or some of your convenience methods might accept an option default
parameter, to be passed on to the appropriate JArgs getOption method.
This shouldn't multiply the number of methods that you've created.

I'm not going to deliberately complicate things so as to scupper your
argument, but in the case of the processing I was doing at this stage,
some of the String option values could only have certain values (they
referred to input and output formats, actually). I have enums defined
for this purpose, so for some of the String options the retrieved values
were immediately converted to enum instances. Other Strings were
freeform so no such processing was appropriate.

That's another method right there, at a minimum. Let us say one extra.

Similarly, a couple of the String options represented file names. Rather
than set them as generic Strings into my own "command line options"
object, I wanted them to be Files. Null is not an acceptable value for
the java.io.File ctor, so at the very least I had to look for null for
_these_ particular String options; "" is OK for java.io.File but it's
not OK for my app.

Hence a bit of specialized "String options meant to be filenames"
processing for some options.

This would/could be an extra convenience method of its own.

In summary, looking at my actual application command line options
(including which option datatypes I actually use), something like a
dozen of them [1], one could create half a dozen convenience methods
that would be used instead.

I don't think I can credibly argue that using the methods would be
worse. I am just not convinced it would be better. :-)

AHS

1. I think the number of options I have is justified. I probably could
have reasonably added a couple more. I've been using getopt and GNU
enhanced getopt and shell getopts for well over 20 years. When I first
encountered these beasts, after going through the usual exercise of
writing my own C.L. handling in C, I'll admit to having gone overboard.
But I'd like to think I am more sensible now: good command line design
is based on lots of usability experience with a dash of artistry.

-- 
...wherever the people are well informed they can be trusted with their
own government...
-- Thomas Jefferson, 1789

Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-15 11:50 -0400
  Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-15 17:10 +0100
  Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-15 17:32 +0100
    Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:21 -0800
    Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-16 07:59 +0100
  Re: Blocks for scope control markspace <-@.> - 2012-01-15 09:57 -0800
    Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:28 -0800
  Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 11:00 -0800
    Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-15 17:49 -0400
      Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-15 15:45 -0800
        Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-19 21:54 -0400
          Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-20 08:41 +0100
            Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 15:24 -0800
            Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-20 19:30 -0400
              Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 15:54 -0800
      Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-16 07:55 +0100
        Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-19 21:16 -0400
          Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-21 13:25 +0100
            Re: Blocks for scope control Arved Sandstrom <asandstrom3minus1@eastlink.ca> - 2012-01-21 10:41 -0400
              Re: Blocks for scope control Robert Klemme <shortcutter@googlemail.com> - 2012-01-22 13:03 +0100
  Re: Blocks for scope control Roedy Green <see_website@mindprod.com.invalid> - 2012-01-16 06:09 -0800
    Re: Blocks for scope control Henk van Voorthuijsen <voorth@xs4all.nl> - 2012-01-16 07:03 -0800
  Re: Blocks for scope control Arne Vajhøj <arne@vajhoej.dk> - 2012-01-17 18:43 -0500
  Re: Blocks for scope control Lew <noone@lewscanon.com> - 2012-01-20 11:05 -0800
  Re: Blocks for scope control Gene Wirchenko <genew@ocis.net> - 2012-01-20 12:11 -0800
  Re: Blocks for scope control Arne Vajhøj <arne@vajhoej.dk> - 2012-02-06 21:24 -0500

csiph-web