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

[A.T. Hofkamp]

On Fri, 8 Mar 2002, Greg Ward wrote:

> 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.

On the other hand, if an experiment succeeds to deliver something useful, we
should adopt it. Note that even my experiment is better than getopt, so
theoretically, it is a candidate solution :-)

> > - 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

I think not, given the gap between what packages deliver and what programmers
need.

> 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

Yes there is, My idea of Options storing the value is an example where
non-object-oriented is better than object-oriented.
On the other hand, as long as more object-orientation delivers more useful
power to the programmer, it is a step in the right direction.

> 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,

I do have some space before being there :-)

> python-dev a case of overgrown formatting classes in Java causing 7000
> function calls every time some app wrote to its log file.  Yow!

Wow, no surprise that Java is not one of the fastest languages in the west.

> 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

Maybe, but generalization is very powerful in finding assumptions that linger
somewhere deep in the code.
Refactoring code for some case makes it easy to dismiss these assumptions as "a
special case", in which case they continue to linger, hindering progress to the
next level.

> generalize/orthogonalize a design simply for the sake of it; rather, you
> should implement, deploy, and *use* the simplest design you can, and

True.
Option processing at first seems to be a very simple operation in essence, and
thus should need very little code. The fact that e.g. Optik (and other option
processing packages as well) are large and complex instead. This is a strong
indication that something fundamental is wrong in the implementation, or
because option processing is not as simple as it looks.
You are not going to find the cause by refactoring, because you are focussed at
details in the code rather than the big picture.

> 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.

I don't do that afaik, at least I seperate experiments from discussions of
whether or not they should be included.

> 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.

Yet the changes are not fundamental. For non-fundamental changes, refactoring
is fine (just potentionally a lot of work).
I try to find the fundamental elements of option processing (and beyond, if
possible). Refactoring will not work there, because it is too much work to drag
all code along.
(that obviously does not exclude the possibility of making fundamental changes
to a package by refactoring, it just takes more effort).


In short, refactoring and making wild experiments are 2 different techniques
aimed at finding out different things. Both have a place in the universe.


Albert
-- 
Constructing a computer program is like writing a painting