[getopt-sig] More about commands on the command line

[Greg Ward]

On 08 March 2002, A.T. Hofkamp said:
> At least some people are not very happy with my experiment to provide a more
> generic approach to option processing. I don't really understand why,
> apparently there is a clash in goals or in the approach of the problem.

Wild experimentation is always a good thing, but it almost certainly
doesn't belong in the Python standard library.  So feel free to perform
your experiments and discuss them here, but keep in mind that the
primary purpose of this SIG is to come up with something better than the
existing getopt module.  Experiments in command-line interface design,
interesting as they may be, are second-class citizens in the discourse
of this SIG.

> Everybody that has read my reasoning and/or my code will have seen
> that I tend to take orthogonality to the limit, and then try to take
> another step. Also, I tend to split everything in as small pieces as
> possible with a single well-defined function. There are a couple of
> reasons for doing that.
> - Having a number of orthogonal pieces that the user can compose in
>   any way he wants gives power to the user. He is able to use the
>   pieces in ways we cannot imagine.

I think others have beaten most of this issue to death, but I'd like to
add one point: there's such a thing as too much orthogonality, or too
much object-orientation.  My case in point is the Java I/O library.  I
only used Java for a little while, and it was two years ago, but the
pain lingers on.  There are about 47 different fiddly little classes
(some of them not so little) involved in writing to a file with Java,
and I spent waaaay more time paging through docs than actually writing
code.  And goodness knows how many method-lookup-and-calls are involved
every time you do a write (or a read).  Someone recently mentioned on
python-dev a case of overgrown formatting classes in Java causing 7000
function calls every time some app wrote to its log file.  Yow!

I think what I'm getting at here can be summed up quite simply:
premature generalization is the root of much evil.  You should never
generalize/orthogonalize a design simply for the sake of it; rather, you
should implement, deploy, and *use* the simplest design you can, and
then refactor as needed.  That way, the divisions between your
classes/modules will fall along the lines actually needed in real life,
not along every possible line you could think of during the design.

At any rate, that's the way I'm approaching Optik.  Starting from two
fundamental classes -- Option and OptionParser -- I have refactored many
methods to make subclassing easier.  Lately, I have been thinking of
factoring a HelpFormatter class out of OptionParser.  I have also been
thinking of splitting the Option class up along "action" lines --
StoreOption, AppendOption, HelpOption, CountOption, etc.  But those
divisions were *not* obvious from the start; they have only become clear
after several months and various attempts to add interesting-but-not-
essential functionality by subclassing.

        Greg
-- 
Greg Ward - programmer-at-big                           gward@python.net
http://starship.python.net/~gward/
I love ROCK 'N ROLL!  I memorized the all WORDS to "WIPE-OUT" in 1965!!