Re: Hi - refactoring Option creation - making a factory

On 25 May 2004, Robert Collins said:
> A few folk over the arch world were looking at build a drop in module to
> extend optik - so that a user can do something like:
> 
> import optparse
> import arch.optparse
> 
> parser=optparse.OptionParser()
> parser.add_option("-a", type="arch-version", action="store", \
>                   dest="version")
> 
> without the bogosity of diddling with the internals of 'Option'.
> 
> We've done a few test cases, and refactored the creation of Option to
> use a factory - which we've called OptionTypes to reflect it's registry
> behaviour.
> 
> I believe we have managed to change this without breaking backwards
> compatability. Attached is the current patch we are working on.

Interesting idea.  After working on the "process default values" patch,
I think I agree about the bogosity of defining custom types.

> With this patch, the documented Best Practice for new style Option
> creation is:
> from arch.optparse import VersionOption
> parser.add_option(VersionOption("-a", action="store", dest="version"))
> which doesn't affect the registry at all.

I don't like this.  I'm very, very fond of the

  parser.add_option("-f", "--foo", ...)

idiom.  If I didn't care about backwards compatibility, I would get rid
of all other ways of defining options and leave only this one standing.
(Unfortunately, I didn't hit upon this idiom immediately when first
developing Optik, so we're stuck with a hodge-podge of ways to define
options.)

The other thing that I don't like about your patch, if I understand it
correctly, is the creation of type-based Option subclasses,
eg. StringOption, ComplexOption, and so forth.  If Option needs to be
refactored, this is the wrong axis to split it along.  Action is by far
more fundamental than type, which argues for splitting by action,
eg. into StoreOption, CountOption, CallbackOption, etc.  The dim
possibility of someday creating those subclasses is what motivated me to
add "make_option = Option" in Optik 1.3.

Nowadays, I'm more inclined to promote action and type to class-hood:
the behaviour of OptionParser should be dictated by instances of
OptionAction and OptionType, which it gets from the Option.  Or
something like that.

Needless to say, this would completely break any code that's adding
custom actions or custom types following the guidelines in
extending.txt.  That means Optik 2.0, and right now I'm interested in
polishing off the outstanding bugs and feature requests to get Optik 1.5
out the door.  I don't see a burning need for massive refactoring right
now.

Anyways, that's as far as I've thought.  I think I'll go back to easy
stuff for now and let refactoring thoughts percolate away in a
low-priority background thread.  ;-)

        Greg
-- 
Greg Ward <[email protected]>                         http://www.gerg.ca/
A day for firm decisions!!!!!  Or is it?


-------------------------------------------------------
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504