[getopt-sig] Extracting data formating from option parser

[Greg Ward]

On 22 February 2002, s. keim said:
> I have already expressed in the list the idea to let the parser delegate 
> string conversion and type checking to an helper object..

I don't see why such a strong separation of duties is needed.  In Optik,
string conversion and type checking are the same: if something can be
converted from a string to the type-of-choice, then it is type-checked.
If not, it is of the wrong type.  

> Even if ,for the moment, I'm only interested in the string->value 
> conversion, in the next part of the document I will call Formatter the 
> object which has the responsibility of data conversion and type checking.

Now you're talking about "data conversion" in addition to "string->value
conversion" and "type checking".  I'm usually quite keen on separation
of duties, but I really don't see the distinction between these three
tasks in the context of command-line argument parsing.

> This is highly inspired from the NSFormatter class of the 
> NextStep/MacOSX framework.
> http://developer.apple.com/techpubs/macosx/Cocoa/Reference/Foundation/Java/
> Classes/NSFormatter.html
> 
> String evaluation is a very common programming task you need it for 
> sample:
> - for interactive user interface
> - text files processing
> - command line management ;)

Ahh.  I think you are suffering from a case of premature
overgeneralization syndrome.  A command-line parsing library should be
geared specifically towards parsing command-line arguments.  It should
not be designed with the hypothetical, "maybe someday" idea that would
could reuse some of it in a GUI toolkit.  If you do that, you'll make
the command line library so arcane and overgeneralized that nobody will
be able to understand it (either for use or maintenance), and it will
*still* have some deep, fundamental assumptions that in the end will
make it a bad fit for GUI programming.  Don't go there.  Keep it simple.

It's pretty rich for me, of all people, to be preaching this, but: make
it as simple as you can and still have it work.  Good rule to follow.

> An then, instead of hard-coding the conversion stuff in the parser, we 
> could reuse predefined Formatter classes:
> parser.add_option("-d",  "--date",  type=DateFormater ("%y/%m/%d") )

Please take a good hard look at the Optik source code, specifically the
Option class in option.py.  It doesn't achieve quite this level of
flexibility, but I didn't view that as a requirement.  But it gets
pretty far with the notion of "type-checking" functions.  All you need
to do to define a new type is write a function that takes a string
value, makes sure it can be converted to your type, and returns a value
of that type.  If your "type" is something like "readable file", then
you might just return the original string unchanged, and the sole
purpose of the type-checking function is type-checking.  Or it might
return a file object -- whatever.

> What are you opinions about this?
> Do you think it would be interesting if I work on a more constructed 
> proposal,  or  is it a definitively bad idea?

Two words: premature overgeneralization!

        Greg
-- 
Greg Ward - just another Python hacker                  gward@python.net
http://starship.python.net/~gward/
Question authority!