Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
As I've said before, if GetOptions() could be a few-lines wrapper
around the $opt = Getopt::Long-new()... $opt-get([EMAIL PROTECTED]) dance,
this allows the author (of what will most likely be a module if they
want to parse something besides ARGV) to design their own entry
point if need be.
I'm puzzled. Basically, you suggest that it is okay to craft your own
entry point
sub MyGetOptions {# [EMAIL PROTECTED], @opts
my $argv = shift;
Getopt::Long-new(@_)-get($argv);
}
while you always disapproved of something like
sub MyGetOptions {# [EMAIL PROTECTED], @opts
local(@ARGV) = @{shift};
GetOptions(@_);
}
There's not a lot of reason to add new functionality into the old
interface because anybody using the new functionality (by
definition) requires the new version.
I can fully agree with that.
-- Johan
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
# The following was supposedly scribed by
# Johan Vromans
# on Saturday 09 July 2005 02:58 am:
this allows the author (of what will most likely be a module if they
want to parse something besides ARGV) to design their own entry
point if need be.
I'm puzzled. Basically, you suggest that it is okay to craft your own
entry point
Right. But this example is too simplistic to show why using an object
and breaking the functionality into method calls is worthwhile. In
this simple case, neither approach comes out ahead.
sub MyGetOptions {# [EMAIL PROTECTED], @opts
my $argv = shift;
Getopt::Long-new(@_)-get($argv);
}
while you always disapproved of something like
sub MyGetOptions {# [EMAIL PROTECTED], @opts
local(@ARGV) = @{shift};
GetOptions(@_);
}
Unless you assign points to clarity. Even though GetOptions is
documented to work on @ARGV, I have to *know* that. This is one more
thing in my head instead of on the screen right in front of me. It's
sort of a distant GOTO that documentation. I wouldn't GOTO a label
in another module, why would it be acceptable if it's a virtual GOTO
that involves perldoc?
Don't try to find too much in my objection to local(@ARGV) = shift
when considering it in isolation. This is just one facet of what I
think could be improved with a step back and a hard look at the overall
architecture.
In Getopt::Crazy, I made GetOptions() operate on @ARGV, because that is
the intended use of that function: It parses *the* command-line
arguments.
When we leave that usage paradigm, suddenly we're breaking the rules of
good design because there's a logic speed-bump in the middle of our
code: Why is this local() here? Oh! Right. GetOptions() isn't
meant to be used like this. (Repeat each time you read the code.)
The more complicated examples better illustrate the advantage of using
objects and methods.
...
$first_pass = Getopt::Long-create(%args);
$next_pass = Getopt::Long-create(\%config, %conf_args);
$first_pass-get([EMAIL PROTECTED], {pass_these = [$next_pass]})
or croak first pass failed;
$next_pass-get([EMAIL PROTECTED]) or croak config pass failed;
foreach my $remainder (@arglist) {
...
}
...
The above might be in main::, but:
1. might also be somewhere in a package like Getopt::Helpful (which
needs a finer-grained access to the configuration to cleanly abstract
the getopt problem while combining it with the config and
documentation)
2. might be in some other module (ala Tk::*) that just wants to provide
an API with position-independent parameters mixed with list items
3. might be in some application which I have not yet imagined (and
therefore I cannot make too many assumptions about its needs)
IMO, the need to do something like getopt() happens so often that it is
almost like a builtin (i.e. It is an aspect of the language.) The
power of Perl does not come so much from the fact that we *can*
accomplish something but from how succinctly we can express it. Some
have said that every point I've raised can be filed under hard things
possible, but I'm seeing patterns in my code and thinking that it
should be simpler.
For the sake of convenience, we've been discussing rather basic examples
and I am partly at fault for not showing enough code to back-up my
English (maybe a rewrite of Randy's Scratchpad.pm would provide a
complex enough example?) The trick with redesigning an architecture is
that you have to consider the combination of all of these simple
issues.
--Eric
--
Peer's Law: The solution to the problem changes the problem.
-
http://scratchcomputing.com
-
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
[EMAIL PROTECTED] (Johan Vromans) writes: [Quoting Sam Vilain, on June 27 2005, 22:56, in Re: Getopt::Long wis] If passing an array ref first doesn't interfere with the calling convention, then imho you don't need to change the function name. Interfere? No, but elegant? Currently, GetOptions allows an array ref as the first argument (to fetch the options from), but it also allows a hash ref as the first argument (to store the options in), while the first argument may also be something typical non-option to designate a different option starter string. For the programmer, there's a very definite order in these 'first' arguments, but I doubt the ordinary (or casual) user will find this easy. Despite this, I now strongly lean towards _not_ creating an additional entry point for this functionality. While GetOptionsFromArray seems nice, there's also a reason for GetOptionsToHash, GetOptionsWithNonStandardIntroducer and so on. This would make code and maintenance unneccessarily complex. So my proposal: * Entry point remains GetOptions * First argument may be an array ref - array to parse options from * First (or next) argument may be a hash ref - hash to put option values in * First (or next) argument, if scalar and not a valid option, may introduce non-standard option introducers. -- Johan
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
On Jul 5, 2005, at 4:44 AM, Johan Vromans wrote: ... I now strongly lean towards _not_ creating an additional entry point for this functionality. While GetOptionsFromArray seems nice, there's also a reason for GetOptionsToHash, GetOptionsWithNonStandardIntroducer and so on. This would make code and maintenance unneccessarily complex. You could easily add a method that accepted named parameters instead of positional (which IMO would improve readability a lot): GetOptions(from = [EMAIL PROTECTED], described_by = [length=i, file=s, verbose], to = \%args, ...); IMO that's usually the right way to make the interface when there are lots of different orthogonal options that the caller might want to employ. How you name the parameters would be up to you, of course. -Ken
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
[Quoting Sam Vilain, on June 27 2005, 11:35, in Re: Getopt::Long wis] Johan Vromans wrote: You mean, you are going to pass things like STDOUT, STDERR, ENV and so on, to every function that may use them? [1] Global things are intended to be global, I'd say. This is why code using CGI.pm is so hard to wrap, too. Assumptions that globals will always be globals. Then you go and try and do anything vaguely re-entrant and it all falls to pieces. I think there's a fundamental difference between user variables that are used globally (which, indeed, expose the problem you mentioned) and variables that are global by design, like STDOUT and ARGV. Anyway, the next version of Getopt::Long will have the ability to use an arbitrary array instead of ARGV. Now, do you want this to be yet another if the first argument is an array reference ... or yet another :config option? -- Johan
RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
[EMAIL PROTECTED] wrote on Monday, June 27, 2005 9:46 AM
Anyway, the next version of Getopt::Long will have the ability to use
an arbitrary array instead of ARGV.
Now, do you want this to be yet another if the first argument is an
array reference ... or yet another :config option?
Imo it would better to expose a different subroutine name for this.
Ie:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Is that ruled out for some reason?
Yves
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
[Quoting Orton, Yves, on June 27 2005, 10:17, in RE: Getopt::Long wis]
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
GetOptionsFromArray?
-- Johan
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Orton, Yves wrote:
Imo it would better to expose a different subroutine name for this.
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Is that ruled out for some reason?
If you consider the signature a part of the subroutine name, then
simply making it take an arrayref as the first argument is enough
to distinguish it.
in Perl 6 you could say
multi sub GetOptions(Array @ARGV, Pair [EMAIL PROTECTED]) { ... }
is a different subroutine to
multi sub GetOptions(Pair [EMAIL PROTECTED]) { ... }
If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.
But that, of course, is a matter of style ;-)
Sam.
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
[Quoting Sam Vilain, on June 27 2005, 22:56, in Re: Getopt::Long wis] If passing an array ref first doesn't interfere with the calling convention, then imho you don't need to change the function name. Interfere? No, but elegant? Currently, GetOptions allows an array ref as the first argument (to fetch the options from), but it also allows a hash ref as the first argument (to store the options in), while the first argument may also be something typical non-option to designate a different option starter string. For the programmer, there's a very definite order in these 'first' arguments, but I doubt the ordinary (or casual) user will find this easy. -- Johan
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
* Orton, Yves [EMAIL PROTECTED] [2005-06-27 11:25]:
Imo it would better to expose a different subroutine name for this.
Ie:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Sounds like a very good idea to me.
* Johan Vromans [EMAIL PROTECTED] [2005-06-27 11:55]:
GetOptionsFromArray?
I like that name.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
# The following was supposedly scribed by
# Johan Vromans
# on Monday 27 June 2005 02:46 am:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
GetOptionsFromArray?
That sounds like a great idea.
Any chance of it involving an object (and therefore multi-pass support?)
--Eric
--
Atavism n: The recurrence of any peculiarity or disease of an ancestor
in a subsequent generation, usually due to genetic recombination.
-
http://scratchcomputing.com
-
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Johan Vromans wrote: You mean, you are going to pass things like STDOUT, STDERR, ENV and so on, to every function that may use them? [1] Global things are intended to be global, I'd say. This is why code using CGI.pm is so hard to wrap, too. Assumptions that globals will always be globals. Then you go and try and do anything vaguely re-entrant and it all falls to pieces. Sam.
RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern) -) Structured access to the option settings -) Option to pass in something other @ARGV to the arg-processing code. Id be curious what you mean by the first, and Im confused why the obvious solution to the second is not good enough. local @[EMAIL PROTECTED]; Goes a long way you know. Yves
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Greetings, On Mon, Jun 20, 2005 at 11:06:49AM +0100, Orton, Yves wrote: -) Structured access to the option settings -) Option to pass in something other @ARGV to the arg-processing code. Id be curious what you mean by the first, I mean the ability to query Getopt::Long, either by an object method in OO mode or through functions, for a list of recognized options their types (e.g., whether int, bool, string or no arg; their linkage, etc.) and Im confused why the obvious solution to the second is not good enough. local @[EMAIL PROTECTED]; Goes a long way you know. It does, and it works, and it is a stylistic thing perhaps, but although global variables can be made to work, the modern phenomenon of function arguments are very popular. Mx.
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Martyn J. Pearce [EMAIL PROTECTED] writes: It does, and it works, and it is a stylistic thing perhaps, but although global variables can be made to work, the modern phenomenon of function arguments are very popular. You mean, you are going to pass things like STDOUT, STDERR, ENV and so on, to every function that may use them? [1] Global things are intended to be global, I'd say. -- Johan [1] This reminds me of an anecdote while I was at the University. We were taught programming, and the rules were quite strict. No globals, only formal parameters. They even dictated the exact parameter list. Files were not part of the parameters. So when I pointed out that a particular routine that needed to produce output could not access the file they decided that the file should be kept local to the routine. Now that was fun, since opening and closing a file caused the printing system to print a couple of banner pages. When my program completed, I had a big pile of output, instead of just a couple of pages. They quickly changed the rules after that :-).
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
* Orton, Yves [EMAIL PROTECTED] [2005-06-20 12:15]:
Im confused why the obvious solution to the second is not good
enough.
local @[EMAIL PROTECTED];
Goes a long way you know.
I don’t like that at all, myself. It works, sure, but then so
does “local $/”, and guess what’s happening to all the
filehandle-specific globals in Perl 6?
I don’t see how being able to *optionally* say something like
GetOptions(
[EMAIL PROTECTED],
# ...
);
would detract from anything at all. All it takes to implement in
GetOptions() are about two lines of code. (With current calling
conventions; I did look.)
* Johan Vromans [EMAIL PROTECTED] [2005-06-20 14:35]:
You mean, you are going to pass things like STDOUT, STDERR, ENV
and so on, to every function that may use them? [1]
Yeah, and
chomp $foo
is wasteful – we should teach people to just say
do { local *_ = \$foo; chomp; }
Hmm, but where the heck does that strange “select FH” fit in
anywhere?
:-)
I think it’s a good default for GetOptions to process @ARGV.
Noone will dispute that. I also think it would be a good thing to
be able to explicitly pass a different array instead. I can’t see
why anyone would dispute that.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
# The following was supposedly scribed by
# A. Pagaltzis
# on Monday 20 June 2005 08:57 am:
I don’t see how being able to *optionally* say something like
GetOptions(
[EMAIL PROTECTED],
# ...
);
would detract from anything at all.
I don't think you really need to be able to pass a different array to
GetOptions(). After all, that really is just meant for parsing
command-line arguments, which aren't going to be found anywhere besides
@ARGV.
What I do think you need is a way to pass a different array to
*something*, so that wrapping and reusing is easier:
Consider how things change if GetOptions were structured something like
the following instead of having all of that tasty parsing logic stuck
inside of it.
sub GetOptions {
my $self = Getopt::Modern-create(@_);
return($self-get([EMAIL PROTECTED]));
}
Now, if you wanted to write a wrapper (or even an api function (ala Tk)
that took a mixed list of arguments and options), you would just call
$opt-get([EMAIL PROTECTED]) instead of GetOptions().
To me, it mostly comes down to thinking what the heck does ARGV have to
do with anything? everytime I see 'local @ARGV = @arglist'.
--Eric
--
I arise in the morning torn between a desire to improve the world and a
desire to enjoy the world. This makes it hard to plan the day.
--E.B. White
-
http://scratchcomputing.com
-
Re: Getopt::Long wishes (was: RFC: Getopt::Modern)
Le lundi 20 juin 2005 à 09:09, Eric Wilhelm écrivait: # The following was supposedly scribed by # A. Pagaltzis # on Monday 20 June 2005 08:57 am: I don???t see how being able to *optionally* say something like GetOptions( [EMAIL PROTECTED], # ... ); would detract from anything at all. I don't think you really need to be able to pass a different array to GetOptions(). After all, that really is just meant for parsing command-line arguments, which aren't going to be found anywhere besides @ARGV. Well, that's a strong assumption. Perl::Tidy, for instance, uses Getopt::Long to parse its parameter list, which has nothing to do with @ARGV. And see http://rt.cpan.org/NoAuth/Bug.html?id=7964 for the kind of trouble that happens when a library uses another library that has a global configuration. In that case, local @ARGV = @whatever is not enough. -- Philippe BooK Bruhat The best thing about being apart is getting together again. (Moral from Groo The Wanderer #39 (Epic))
Re: RFC: Getopt::Modern
A. Pagaltzis [EMAIL PROTECTED] writes: Something like ++ instead of --. I think thats ugly. Id suggest simply addding another dash [...] I find it very interesting to note that although we're talking about quite different semantics, everyone seems to be wanting to stick to the ancient syntax of --style command line options. It's like wanting to have a shell window on Windows/XP, and then control GUI applications from the command line. Nobody would want that. I have several tools that take different syntax on the command line, specific for the task. For example, subcommands: mycmd init db=$HOME/mydb mycmd load db=$HOME/mydb data1 mycmd load --trace db=$HOME/mydb data1 mycmd --trace load db=$HOME/mydb data1 Note that the 3rd and 4th commands behave significantly different. Now, I could have forced this in the --style command line look: mycmd --command=init --db=$HOME/mydb mycmd --command=load --db=$HOME/mydb data1 mycmd --command=load --trace --db=$HOME/mydb data1 mycmd --trace --command=load --db=$HOME/mydb data1 but besides requiring more typing, it looses the distinction that --command and --db are not options in the common sense. --db is not an option, it's mandatory. And the (sub)command selection controls which (real command line) options are further recognized. So if you want something different, why not do it differently? -- Johan
Re: RFC: Getopt::Modern
* Johan Vromans [EMAIL PROTECTED] [2005-06-19 11:15]:
I find it very interesting to note that although we're talking
about quite different semantics, everyone seems to be wanting
to stick to the ancient syntax of --style command line
options.
I dont see why it is ancient instead of sensible. You mean
that you think its not a good fit for this particular case; and
Ive already said at least twice that the exemplified command
line interface to Erics hypothetical shopping tool is atrocious.
It's like wanting to have a shell window on Windows/XP, and
then control GUI applications from the command line. Nobody
would want that.
Nobody? What you say would actually be very useful to be able to
do.
I have several tools that take different syntax on the command line,
specific for the task. For example, subcommands:
mycmd init db=$HOME/mydb
mycmd load db=$HOME/mydb data1
mycmd load --trace db=$HOME/mydb data1
mycmd --trace load db=$HOME/mydb data1
Note that the 3rd and 4th commands behave significantly different.
This works fine so long as the non-option arguments have fixed
positions or your command line does not deal with files.
Several of my scripts use that style, as appropriate.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
Johan Vromans wrote: I have several tools that take different syntax on the command line, specific for the task. For example, subcommands: mycmd init db=$HOME/mydb mycmd load db=$HOME/mydb data1 mycmd load --trace db=$HOME/mydb data1 mycmd --trace load db=$HOME/mydb data1 Yes; I've wanted to do this before, and commands like svn, svk, etc are good examples of this... I've jumped through all sorts of hoops before cordinating getting this right from the command line and config files at once... However I must admit I found Getopt::Long provided me with the API I needed to do the command line parsing part easily and flexibly enough. Sam.
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: Ok. Then my previous argument stands. If the --no- means unset any hard-coded or config-file defaults, then it shouldn't be evaluated in command-line order. Good deduction, but the premise does not hold. --no- does not mean unset any [...] defaults, it means: set the option value to 'false'. And b) mixing options and arguments, where --foo arg1 --no-foo arg2 means that arg1 is processed with --foo and arg2 with --no-foo. This is not something I'm trying to address. That's okay. There are several Getopt:: modules that implement a simplified subset of Getopt::Long for various reasons. -- Johan
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: Independent of percentages, why disallow --foo --no-foo provided there's a clear definition of the semantics? I never suggested that it should be disallowed. Only that it should be equivalent to '--no-foo --foo'. That's part of the clearly defined semantics. The problem that I see is legacy. Many users expect the left-to-right behaviour, and will get confused if some tools act differently. (And no, I do not have a good solution for that.) -- Johan
Re: RFC: Getopt::Modern
On Thu, 2005-06-16 at 20:12 -0700, Eric Wilhelm wrote: The purpose of a negated option is (in all of the usages that I have seen) to reset any hard-coded or config-file variable. This is not the purpose, see my other posting. -- Johan
Re: RFC: Getopt::Modern
On Sat, Jun 18, 2005 at 10:44:21AM +0200, Johan Vromans wrote: The problem that I see is legacy. Many users expect the left-to-right behaviour, and will get confused if some tools act differently. I don't think that's merely legacy; the majority of those on this list who have expressed a preference have said they prefer it that way. Mx.
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: What I'm trying to do with Getopt::Modern here is to establish some conventions which allow this to happen internally. This saves the author some code and gives the user a guaranteed consistent experience with multiple programs. The debate on the usefullness of '--no-' appears to say it's useful. The debate on its behavior says that there are historical (and convenience) reasons to keep its evaluation in command-line order. What I'll probably end-up with is something like '--un-' performing the above task of initializing internal values. I'd strongly suggest that if you really break the long standing conventions, even for perfectly valid reasons!, please select a distinctive form so users know what to expect. In an earlier message I referred to the former GNU convention of starting the (then new style of) command line options with a + instead of a minus. -- Johan
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: Because I had originally built that as a wrapper around Getopt::Long, I had a laundry-list of what didn't work. This would have been interesting for me to know. In fact, as I mentioned I would be happy for G::L to have this functionality, but I doubt that program-order evaluation (one of the main design goals) is going to fit without some serious restructuring. It might require serious restructuring, but I'm not afraid of that. I usually rewrite/refactor most of my programs when I get bored :-). Do you have a project page for your recent work? Though not recent, http://www.squirrel.nl/people/jvromans/sw_getopt3.html reveals some of the ideas behind G::L version 3. -- Johan
Re: RFC: Getopt::Modern
To Eric,
Some might-be-helpful thoughts for you:
1. Bundling Problem on Getopt::Long:
Yes, I was very troubled for that problem before. I even had a same
thought as you to parse the arguments by myself. But after a couple of
tries I gave up. My codes get all messed up. Then I found my life could
be easier with Getopt::Long. Now I have neat codes. Bundling problem?
I never document the use of bundled options. It's OK if they hack and
try that. But I'm not their mon. For me, controlling them for their
possibility is non-sense. They take their own responsibility for its
behavior. They can hack, and they can have fun.
You may not agree with me. That's fine. Bundling problem is rather
complicated. It's a challenge to anyone. I won't get jealous if you
solved it and I couldn't. ^_^
2. The --no-fish or --un-fish Issue:
Actually, if I were you, I would use --no-default-fish, or
--no-def-fish. With
go_shop --fish tuna --fish halibut --no-default-fish
go_shop --no-default-fish --fish tuna --fish halibut
it makes perfect sense that these commands should get the same
result. It reads naturally.
3. The 2 Lines Example:
Actually, I can deduce it into one. The use of the $opt_nofish
variable is non-sense.
Getopt::Long::GetOptions(
fish=s = [EMAIL PROTECTED],
no-default-fish = sub { @conf_fishes = qw() },
);
@fishes = (@conf_fishes, @opt_fishes);
As I said, you can work in a more flexible way on this issue. You
might originally be tied to the impression of:
Getopt::Long::GetOptions(
verbose! = \$verbose,
);
which may only be one convienent usage of Getopt::Long.
--
Best regards,
imacat ^_*' [EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt
Woman's Voice News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug
pgpH7Ryuq5AcL.pgp
Description: PGP signature
Re: RFC: Getopt::Modern
# The following was supposedly scribed by # Johan Vromans # on Saturday 18 June 2005 03:37 am: What I'll probably end-up with is something like '--un-' performing the above task of initializing internal values. I'd strongly suggest that if you really break the long standing conventions, even for perfectly valid reasons!, please select a distinctive form so users know what to expect. Is '--un-' not distinctive enough? I've got this much of the design written-up already: http://scratchcomputing.com/developers/Getopt-Crazy/ As I said, since '--no-' is used so much and historically is expected to behave in a certain way, I won't be changing that at all. Basically, I had just never wanted to use it that way and was therefore looking for a new kind of behavior which plays nicely with config-files. --Eric -- Politics is not a bad profession. If you succeed there are many rewards, if you disgrace yourself you can always write a book. --Ronald Reagan - http://scratchcomputing.com -
Re: RFC: Getopt::Modern
imacat [EMAIL PROTECTED] writes: [...] But, then, is this whole thread that meaningless? I don't think so. Many good ideas and suggestions have come by, and though not all ideas are equally viable, many people spend energy on communicating ideas -- which is fundamental to open source software. -- Johan
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: Maybe we'll even manage to hammer it into a standard. That would really be nice! -- Johan
Re: RFC: Getopt::Modern
Orton, Yves [EMAIL PROTECTED] writes: I currently have two projects that address this issue: Getopt::Toolkit (which is based on Getopt::Long) and Getopt::Long version 3 (which is a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two projects into a single new Getopt::Long version is somewhere on my TODO list. HOWEVER, since I highly appreciate my happy users, whatever comes out of the merge will be drop-in compatible with the current Getopt::Long. If this implies that you will not use it because it is too flexible, that's fine with me. One unhappy user against a zillion happy users. OOOH. Maybe I shouldn't upload Getopt::Long::INI after all... Don't hold your breath (see some other messages of mine). Besides, I'd like to reserve the Getopt::Long::* namespace for Getopt::Long internal modules... -- Johan
Re: RFC: Getopt::Modern
* Johan Vromans [EMAIL PROTECTED] [2005-06-18 23:20]: Eric Wilhelm [EMAIL PROTECTED] writes: Is '--un-' not distinctive enough? I believe there's more involved that adding the --un- semantics. For example, precedence order parsing yields different results from left to right parsing. I agree that --un- alone is not distinctive you want something that tells the user this *looks* *so* different that it probably *behaves* differently too, and simply using an un prefix to the option is not enough for that. OTOH, with a switch like --no-default-fish the semantics should be obvious from the description itself. In this respect the un prefix is really horribly chosen. I dont know about anyone else here, but if I saw that I could tell this hypothetical shopping application that I want --un-fish, Id have no idea what thats supposed to mean, whereas the meaning of --fish blah or --no-fish (in the traditional sense of the no prefix!) is immediately obvious. Something like ++ instead of --. I think thats ugly. Id suggest simply addding another dash to signify the altered precedence, as in ---. It is also slightly evocative in a linguistic sense as the ASCII rendering of an em-dash, so you could think of it as a break in the sentence youre writing on the command line something that can be added as an afterthought, like the subclause youre reading right now. For this hypothetical shopping application Id probably be most inclined to have a --no-default switch which takes a type or a list thereof as its argument, so the user could say --no-defaultfish,meat,fruit. With the tripple dash, Id call it something else (though I dont quite know what), but itd work the same way. Regards, -- Aristotle Like punning, programming is a play on words. Alan J. Perlis, Epigrams in Programming
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: You wouldn't say --foo --no-foo if you just meant --no-foo Would you? I think the basic question is, what do you expect from a certain combination of options and arguments. For example, --foo arg1 --no-foo arg2 This can be interpreted as: process arg1 and arg2 with $foo == 0 process arg1 and arg2 with $foo == 1 process arg1 with $foo == 1, and arg2 with $foo == 0 process arg1, --no-foo and arg2 with $foo == 1 Even more exotic possibilities: process something with $foo == arg1 and $no_foo == arg2 process arg2 with @foo == qw(--no-foo arg2) process something with @foo == qw(arg1 --no-foo arg2) and so on As I wrote in an earlier message, there's no real standard on what interpretation is correct, hence they all have a reason for being there. And Getopt::Long handles all of them (and more). Too much flexibility? Maybe. But where does the flexibility get in the way? Using configuration options, most of the flexibility can be controlled. -- Johan
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: Do you mean to say that 99% of the time (when --foo and --no-foo are both present) that it is because somebody has an alias with a --foo flag written into it? Independent of percentages, why disallow --foo --no-foo provided there's a clear definition of the semantics? -- Johan
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: Ok, and maybe I showing my age here, but is *this* where the negated-options thing comes from? I.E. is this the historic (and entire) reason for having the 'foo!' syntax in Getopt::Long? No, it's because of a) defaults. Sometimes a flag is enabled by default, sometimes its disabled by default. Having both the --foo and --no-foo options it is always possible to exactly define what you want the current invokation of the command to do, regardless of any default settings. It's user-friendly redundancy. And b) mixing options and arguments, where --foo arg1 --no-foo arg2 means that arg1 is processed with --foo and arg2 with --no-foo. -- Johan
Re: RFC: Getopt::Modern
Eric Wilhelm [EMAIL PROTECTED] writes: Please see this essay http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt Nice piece of writing, but it contains several flaws. For example: If your spouse tells you to get tuna and halibut, but not any other fish, you would probably get in trouble if you returned from the store with no fish, and yet this is what programmers seem to expect from the following command-line: go_shop --fish tuna --fish halibut --no-fish But the results should be the same as below: go_shop --no-fish --fish tuna --fish halibut However, the equivalent of go_shop --fish tuna --fish halibut --no-fish is the spouse telling tuna and halibut, but no fish. Now, if my spouse starts telling me things like that, I've got reasons to start worrying about her mental health. But the bottom line of your essay is that human logic is not computer logic (which is true) and that programmers (and computer users) often abide with computer logic instead of human logic. When my wife tells me to get tuna and halibut, but no fish, I'll ask her what do you mean. As for the command line options, using go_shop --fish tuna --fish halibut --no-fish should result in an error message like ambiguous use of conflicting options or something. All other interpretations are, according to human logic, wrong. But then there's that nasty little fact that's called history: we've done it according to computer logic for 50 years or so, and it is not easy to break habits. I think for this reason the original GNU options parser used a + prefix to indicate that this option was going to be interpreted differently than ususal. -- Johan
Re: RFC: Getopt::Modern
On Fri, 17 Jun 2005 10:57:26 +0200 Johan Vromans [EMAIL PROTECTED] wrote: Eric Wilhelm [EMAIL PROTECTED] writes: Please see this essay http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt If your spouse tells you to get tuna and halibut, but not any other fish, you would probably get in trouble if you returned from the store with no fish, and yet this is what programmers seem to expect from the following command-line: go_shop --fish tuna --fish halibut --no-fish But the results should be the same as below: go_shop --no-fish --fish tuna --fish halibut To Eric, I did not notice the go_shop problem. But I think it's trivial to solve that with Getopt::Long: my @conf_fishes = read_conf(fish); # get qw(trout) my @opt_fishes = qw(); my $opt_nofish = 0; Getopt::Long::GetOptions( fish=s = [EMAIL PROTECTED], no-fish = \$opt_nofish, ); @conf_fishes = qw() if $opt_nofish; my @fishes = (@conf_fishes, @opt_fishes); Who said the variable to save the no-fish status has to be revelant with the fish variable anyway? If they are saved in different variables, the order doesn't matter, does it? -- Best regards, imacat ^_*' [EMAIL PROTECTED] PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug pgpf9fwozK3Jp.pgp Description: PGP signature
Re: RFC: Getopt::Modern
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 01:35]:
I dont understand. If there was no need to be able to say
--foo --no-foo, then why do both exist?
No, no, no. Start over.
1. There is a need.
2. It doesn't matter what order the user gives the options in,
the result should be the same.
Wait, why start over? Im asking what this need is. I want to
know which things we are trying to achieve. If we dont know
that, how will we know when we achieved them?
Did you read the essay about why order doesn't matter?
I did now and I didnt see anything new that hasnt been
mentioned in this thread already.
First, to get the show stopper out of the way, your proposed
model is trivial to implement in terms of Getopt::Long.
my $verbosity = 5;
GetOptions(
'v|verbose' = \( my $opt_verbinc = 0 ),
'no-verbose' = sub { $verbosity = 0 },
);
$verbosity += $opt_verbinc;
$verbosity = 10 if $verbosity 10;
Clear, self-documenting code.
Second, you are using a weird and unusual example to support your
arguments: a ranged variable option that is incremented using
binary switches.
The only case where Ive ever seen that model used is precisely
for the -v verbosity switch. The first I encountered it, I
thought it was strange. Of note that a program typically has only
one switch which behaves this way, and that Ive never seen
anyone write -vxyvjvkv rather than -xyjk.
Thus, I posit that this model is wrong in most cases.
It seems that accumulative switches are all that you are really
talking about.
I therefore further posit that the switch you called
--no-verbose is a misnomer.
It should be called --start-verbose=0, which indeed should be
parsed in precedence order rather than command line order. --foo
--no-foo makes sense in mathematic terms, not in linguistic
ones. Certainly its not anywhere as obvious an expression of
your intent as something like --foo --start-foo=0 is.
This model is even easier to implement in terms of Getopt::Long.
GetOptions(
'v|verbose' = \( my $opt_verbinc = 0 ),
'start-verbose=i' = \( my $opt_startverb = 5 ),
);
my $verbosity = $opt_startverb + $opt_verbinc;
And no, you cant tell what option comes from an alias and which
doesnt. Even if you could, that wouldnt cover cases like
my @cmd = qw( foo --bar --baz );
if( $something ) { system @cmd, qw( blah blah ) }
elsif( $other ) { system @cmd, '--wibble', @wibble }
elsif( $whatev ) { system @cmd, '--wubble', @wibble }
else { system @cmd, qw( --no-bar blah blah ) }
What youre asking the --no-foo mechanism to do for you it
neither something its meant to do nor something its a good
literary choice for.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
On Jun 16, 2005, at 10:33 PM, Ken Williams wrote: For a counterexample, please see the -f and -i options to /bin/rm. Many people, myself included, have found it exceptionally useful that the final switch takes precedence, because then we can do things like alias ls ls -i and still be able to use the -f switch when we need to. Er, not ls. rm. Gee, I thought I was writing such a clear message... -Ken
Re: RFC: Getopt::Modern
On Jun 16, 2005, at 11:04 PM, Eric Wilhelm wrote: Ok, and maybe I showing my age here, but is *this* where the negated-options thing comes from? I.E. is this the historic (and entire) reason for having the 'foo!' syntax in Getopt::Long? If so, is that why there is so much resistance to evaluating in anything besides command-line order? I dunno. Personally, I think you should just write your module. =) Don't call it ::Modern or ::User, because clearly there's a lot of disagreement among the users here, call it something like ::NonExclusive. But it seems like the worst that could happen is that people don't use it. -Ken
RE: RFC: Getopt::Modern
Title: RE: RFC: Getopt::Modern
[Quoting Eric Wilhelm, on June 16 2005, 15:14, in Re: RFC:
Getopt::Mo]
15 years * n requests/year = 15*n degrees of flexibility =
unpredictable
Hmm. I'd say
15 years * n requests/year * m happy users = reliability
which is as meaningless as your formula.
Its not just happyness with the reliability, its also the reliability of the author. I know for a fact that Johan responds to patches and bug fixes and feature requests quickly, and usually in a way that makes the user happy. (I think he turned down one patch of mine, but applied at least two or three so im happy with those odds.) OTOH, and no offence Eric, I don't know about you and your responsiveness. ID say its pretty hard to beat Johans.
True, but Getoptions() currently contains all of the expertness of
G::L, which means that other modules cannot learn anything about the
options (such as when Getopt::Helpful would like to know if these are
simple/float/list/hash, etc options without re-implementing G::L's
parsing.)
I can make this information available, if users would be interested.
Well, you already published the rules for parsing the options which was all I needed to write a wrapper around G::L to have it integrate INI file configuration and an a simplified interface for implementing defaults and options in a single hash.
If you tear it apart and put it back together in pieces,
How I do it, is my responsibility.
Agreed. So long as the parse rules don't change bizarrely IMO publishing them should be sufficient.
* multi-pass support
I think this is possibly the only real improvement to G::L.
And, (from my reading of G::L) one that requires a fundamental
restructuring of the code.
Unless I misunderstand what you mean by multipass here I think you are wrong:
{
local @[EMAIL PROTECTED];
Getoptions();
}
Getoptions();
Done. And that's exactly what I do in Getopt::Long::INI (which thanks to this thread I now remember I need to upload to CPAN.)
I currently have two projects that address this issue: Getopt::Toolkit
(which is based on Getopt::Long) and Getopt::Long version 3 (which is
a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two
projects into a single new Getopt::Long version is somewhere on my
TODO list. HOWEVER, since I highly appreciate my happy users, whatever
comes out of the merge will be drop-in compatible with the current
Getopt::Long. If this implies that you will not use it because it is
too flexible, that's fine with me. One unhappy user against a zillion
happy users.
OOOH. Maybe I shouldn't upload Getopt::Long::INI after all...
Anychance of some previews?
Finally, I must say, your web site makes me sad.
I can see why. Just so you know many of us hold G::L and yourself in high regard.
Cheers,
Yves
Re: RFC: Getopt::Modern
# The following was supposedly scribed by # Johan Vromans # on Friday 17 June 2005 12:55 am: Do you mean to say that 99% of the time (when --foo and --no-foo are both present) that it is because somebody has an alias with a --foo flag written into it? Independent of percentages, why disallow --foo --no-foo provided there's a clear definition of the semantics? I never suggested that it should be disallowed. Only that it should be equivalent to '--no-foo --foo'. --Eric -- Unthinking respect for authority is the greatest enemy of truth. --Albert Einstein - http://scratchcomputing.com -
Getopt::Long wishes (was: RFC: Getopt::Modern)
* Johan Vromans [EMAIL PROTECTED] [2005-06-17 17:20]:
I can make this information available, if users would be
interested.
Access to structured data is always nicer than implementing and
re-implemeting a parser for its serialized form.
So if it doesnt take too much effort, it would be nice to have.
I might even need this at some point (Im the current maintainer
of Getopt::Auto, though I must admit I have not done much to earn
the title yet).
One unhappy user against a zillion happy users.
Since were at this: the one thing I still fall back to
Getopt::Std for is small scripts. I love Getopt::Long, but it
incurs a pretty high startup cost. Is there any chance you can
play some deferred compilation cards to make it go faster?
Of course, its kind of tricky for a module whose code all runs
exactly once, at program startup maybe you can isolate the code
that implements various features and compile only those which are
actually requested/used? Of course, I have no idea what Im
talking about, given that I havent taken even a cursory look at
the code.
I just thought Id throw these out here while were at the topic,
before I get distracted by some other shiny ball.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
# The following was supposedly scribed by # imacat # on Friday 17 June 2005 02:51 am: I did not notice the go_shop problem. But I think it's trivial to solve that with Getopt::Long: my @conf_fishes = read_conf(fish); # get qw(trout) my @opt_fishes = qw(); my $opt_nofish = 0; Getopt::Long::GetOptions( fish=s = [EMAIL PROTECTED], no-fish = \$opt_nofish, ); @conf_fishes = qw() if $opt_nofish; my @fishes = (@conf_fishes, @opt_fishes); Yes. You can solve it. It's not really trivial by the time you add meats, cheeses, breads, and mustard though. All of these things come in many flavors and you might have a config file with your favorites listed in it so that running go_shop with no arguments gives you a routine trip, but you want to be able to change these things when you get bored of the same-old options. These 4 extra lines multiply by 5 items so far. Who said the variable to save the no-fish status has to be revelant with the fish variable anyway? If they are saved in different variables, the order doesn't matter, does it? What I'm trying to do with Getopt::Modern here is to establish some conventions which allow this to happen internally. This saves the author some code and gives the user a guaranteed consistent experience with multiple programs. The debate on the usefullness of '--no-' appears to say it's useful. The debate on its behavior says that there are historical (and convenience) reasons to keep its evaluation in command-line order. What I'll probably end-up with is something like '--un-' performing the above task of initializing internal values. --Eric -- Everything goes wrong all at once. --Quantized Revision of Murphy's Law - http://scratchcomputing.com -
Re: RFC: Getopt::Modern
On Fri, 17 Jun 2005 08:45:26 -0700 Eric Wilhelm [EMAIL PROTECTED] wrote: Ok. Then my previous argument stands. If the --no- means unset any hard-coded or config-file defaults, then it shouldn't be evaluated in command-line order. Well, as I said, if you would like unordered options, simply put foo and no-foo in 2 different variables seperately. It's just the flexibility you accused on Getopt::Long that may solve your problem in 2 lines, but not having to write a whole new module. Getopt::Long::GetOptions( fish=s = [EMAIL PROTECTED], no-fish = \$opt_nofish, ); @conf_fishes = qw() if $opt_nofish; @fishes = (@conf_fishes, @opt_fishes); -- Best regards, imacat ^_*' [EMAIL PROTECTED] PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug pgpN0cxhOyIAb.pgp Description: PGP signature
Re: RFC: Getopt::Modern
# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 08:14 am:
If it involves typing @main::ARGV, something is wrong.
This is another one of your statements that feel like a religious
issue. If typing @main::ARGV indicates that something is wrong, I
think you have to address the Perl design and maintenance team.
This is not about the look of the variable name. It's about a package
modifying a global variable deep inside the core of its functionality.
Here's how I addressed the issue. There's only one instance of ARGV in
the code. get() doesn't care what you pass it, so it's easier to wrap.
You could even use it for parsing hash values in API functions.
sub GetOptions {
my $self = Getopt::Modern-create(@_);
return($self-get([EMAIL PROTECTED]));
}
I was wrong about that being @main::ARGV. It's just @ARGV.
Anyway, this GetOptions() function is not meant to be wrapped, and it
serves as a dirt-simple example of what to do if you want to wrap
Getopt::Modern.
--Eric
--
Don't worry about what anybody else is going to do. The best way to
predict the future is to invent it.
--Alan Kay
-
http://scratchcomputing.com
-
Re: RFC: Getopt::Modern
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:00]:
In fact, as I mentioned I would be happy for G::L to have this
functionality, but I doubt that program-order evaluation (one
of the main design goals) is going to fit without some serious
restructuring.
Why do you keep claiming that? Both me and someone else already
posted working code that shows how you can trivially do what you
want with Getopt::Long if you just use two different variables.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:20]:
In any case. How does G::L evaluate in precedence order?
That's why I'm writing G::?
By parsing into two separate variables, and allowing separate
module-client code evaluate how to react to the values in those
to variables. A working example of code that does this is in the
part of my message that you conveniently snipped.
There are other useful situations for controlling the order.
We just haven't covered them yet.
Which cant be addressed using quite the same approach as the one
that has already been shown to work for this case? I am doubtful,
but go ahead, convince me.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
On Fri, 17 Jun 2005 09:08:51 -0700 Eric Wilhelm [EMAIL PROTECTED] wrote: Yes. You can solve it. It's not really trivial by the time you add meats, cheeses, breads, and mustard though. All of these things come in many flavors and you might have a config file with your favorites listed in it so that running go_shop with no arguments gives you a routine trip, but you want to be able to change these things when you get bored of the same-old options. These 4 extra lines multiply by 5 items so far. It's 2 lines, not 4. Of course, you can request registering a new module to save 2 x 5 = 10 lines of code. Or, as you said, saving 4 x 5 = 20 lines. But mostly when I get an argument of a file name, I have to check it's existence, it's permission, its type, bla bla bla. With proper comments, that takes at least 9 lines for an argument (not an option). In your example, that is 9 lines x 2 arguments x 5 options = 90 lines. This is only the argument parsing. The real code is far more complicated. Last application I wrote take 2442 lines. In such a case, I don't care about saving 10-20 lines or not. To save 10-20 lines, I would rather try another neat algorithm for the main code. Enhancing algorithm of the main code may save 200-300 lines at once. Most applications as complicated as your example exceeds 1000 lines. Saving 10-20 lines for that is non-sense. An application that has only 50 lines may matter, but I doubt its option complexity to have 10-20 lines to save. A new module, with its accompany documentation, its test suite and its future maintainance, takes at least 1500 lines. The usefulness of controlling the option order can be done in 2-20 lines with Getopt::Long, and you are going to writing more than 1500 lines just to save them? Na~ I agree with others. If you do think saving 2-20 lines is vital to your application, I would suggest naming it something else than Getopt::Modern. The word Modern poses an attitude of superiority towards its competitors. But everyone here does not agree with that superiority. I think it's rather personal taste, not modernity. I would *not* suggest, say, Getopt::Save20Lines, by the way. :p -- Best regards, imacat ^_*' [EMAIL PROTECTED] PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug pgp6X2jG2ksI6.pgp Description: PGP signature
Re: RFC: Getopt::Modern
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:15]:
It's not really trivial by the time you add meats, cheeses,
breads, and mustard though. All of these things come in many
flavors and you might have a config file with your favorites
listed in it so that running go_shop with no arguments gives
you a routine trip, but you want to be able to change these
things when you get bored of the same-old options.
Thats not trivial, period. Any solution will have to be pretty
complex if its supposed to handle this especially if you want
the user to be able to override only some defaults, but not
others. Im not sure that any form of command line will be
anything other than craptacular for a job like this.
This would all be much easier if we had actual examples to
discuss.
What I'm trying to do with Getopt::Modern here is to establish
some conventions which allow this to happen internally. This
saves the author some code and gives the user a guaranteed
consistent experience with multiple programs.
Thats never going to happen for the users. There are way too
many other programs already out there. Most of them work
differently from yours.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
--- A. Pagaltzis [EMAIL PROTECTED] wrote: Why do you keep claiming that? Both me and someone else already posted working code that shows how you can trivially do what you want with Getopt::Long if you just use two different variables. Which, to me, is the clincher. Getopt::Long can easily support what Eric wants. There's been an awful lot of energy spent in this thread over something which most don't see as an issue. I'm still trying to figure out why it's carried on this long. Cheers, Ovid -- If this message is a response to a question on a mailing list, please send follow up questions to the list. Web Programming with Perl -- http://users.easystreet.com/ovid/cgi_course/
Re: RFC: Getopt::Modern
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote: * Ovid [EMAIL PROTECTED] [2005-06-17 20:15]: I'm still trying to figure out why it's carried on this long. Calling the new module ::Modern and claiming that ::Long is crufty, too flexible, and unpredictable probably set the mood. Amen. Eric, that was really obnoxious. You might have had more luck convincing people that your approach had some merit if you were less haughty about it. -Ken
Re: RFC: Getopt::Modern
On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote: On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote: * Ovid [EMAIL PROTECTED] [2005-06-17 20:15]: I'm still trying to figure out why it's carried on this long. Calling the new module ::Modern and claiming that ::Long is crufty, too flexible, and unpredictable probably set the mood. Amen. Eric, that was really obnoxious. You might have had more luck convincing people that your approach had some merit if you were less haughty about it. Imagine this is Eric's first try at publishing a module. While perhaps his approach could use honing, perhaps we could make it a little less of a smackdown? It would be nice to encourage contribution to the community. Austin
Re: RFC: Getopt::Modern
# The following was supposedly scribed by # Ken Williams # on Friday 17 June 2005 01:07 pm: Calling the new module ::Modern and claiming that ::Long is crufty, too flexible, and unpredictable probably set the mood. Amen. Eric, that was really obnoxious. You might have had more luck convincing people that your approach had some merit if you were less haughty about it. Ouch! Please note the RFC in the subject. That's not Requests For Congratulations and Clamoring new users. This is a work in progress, and I was requesting (primarily) feedback on the name (which I *know* is a dumb name (no. Really. The dumbest name I've ever thought of.)) Had I used Getopt::WorkingTitle, would this discussion have been rosier? My slides contain some notes about what I was trying to fix in G::L. There were some scathing objections to my take on how the option processing should behave. So, I was trying to get to the bottom of the logic (past the religious fervor, etc, etc.) What I've learned about this is that: 1. Historically, --no- was intended to reset hard-coded and config-file options. 2. Since then, lots of people have been using it to override aliased options (and as a fancy backspace key) (taking advantage of the coincidental command-order of implementation detail.) Where I'm going from here: 1. History wins the '--no-'. Fine. That doesn't mean we can't move forward. 2. More examples on the program-order evaluation, which appears to be largely misunderstood. 3. A clearly written set of design objectives, for my sake and the sake of discussion. Hell. Maybe we'll even manage to hammer it into a standard. The trouble with open-source is that instead of cursing a black-box, I'm able to dig through the code that's not doing what I want and find what needs to change. So, I curse what needs fixing (of course this is only what *I* see as needing fixing by definition I'm incapable of seeing anything else) in there without stopping to say: Wow! This module really does some great stuff! Isn't perl beautiful and I'm really impressed at what Getopt::Long is so far. Pats on the back for everybody and smiles all around. Now. Let's get to work because we can do better. I am grateful to everyone who participated in the discussion. Without you, there wouldn't have been one. And it was a good discussion. Maybe I'll see a few of you at OSCON. Send me an e-mail off-list and I'll buy you a beer. I do have strong opinions. I also don't surrender them easily. Of course I think I'm great, but I never said I was better than anybody else :-) I'm not posting to seek approval. Tell me this is the dumbest idea you've ever heard and I'll be happy as long as you tell me why because I will have learned something and my code (or at least someone's code) will improve because of it. Thanks, Eric -- We who cut mere stones must always be envisioning cathedrals. --Quarry worker's creed - http://scratchcomputing.com -
Re: RFC: Getopt::Modern
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]:
Imagine this is Eric's first try at publishing a module.
Then what is http://search.cpan.org/~ewilhelm/? :-)
You could take at least a cursory look before making such
assumptions
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
On Fri, Jun 17, 2005 at 11:22:58PM +0200, A. Pagaltzis wrote: * Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]: Imagine this is Eric's first try at publishing a module. Then what is http://search.cpan.org/~ewilhelm/? :-) You could take at least a cursory look before making such assumptions??? Was I assuming, or was I imagining? The point is that the community can be unnecessarily combative and ugly, a point which to my eyes you have helped illustrate. Austin
Re: RFC: Getopt::Modern
On Jun 17, 2005, at 3:37 PM, Austin Schutz wrote: On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote: On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote: * Ovid [EMAIL PROTECTED] [2005-06-17 20:15]: I'm still trying to figure out why it's carried on this long. Calling the new module ::Modern and claiming that ::Long is crufty, too flexible, and unpredictable probably set the mood. Amen. Eric, that was really obnoxious. You might have had more luck convincing people that your approach had some merit if you were less haughty about it. Imagine this is Eric's first try at publishing a module. While perhaps his approach could use honing, perhaps we could make it a little less of a smackdown? It would be nice to encourage contribution to the community. True, I guess my message was at least as obnoxious. Eric isn't a newbie author, though, he's pretty experienced and has a few good modules under his belt. And as I said in my other message, I do encourage him to go ahead and write the module. It doesn't really matter how many of us disagree with his design proposal - if it scratches his itch, it may well scratch others' itches. -Ken
Re: RFC: Getopt::Modern
On Fri, 17 Jun 2005 14:34:59 -0700 Austin Schutz [EMAIL PROTECTED] wrote: Was I assuming, or was I imagining? The point is that the community can be unnecessarily combative and ugly, a point which to my eyes you have helped illustrate. Well, I suppose, I am one of those you mentioned. Yes, I said something like Getopt::Save20Lines. Though I'm not the one started that (I started to laugh at Johan's Getopt::Personal::EWilhelm), but if that's not appropriate, I apologize. But, then, is this whole thread that meaningless? We people here all took time to try to read, ask and understand what Eric thinks, provide our feedback, explaining this and that. Aristotle and I even figured out a simple solution to Eric's problem. We have proved that Getopt::Long is not unpredictable. It is flexable to solve Eric's major problem. Or maybe everybody here was doing wrong. Should we just say, go ahead, make your day, without even bother to watch his slides and figure out the problem? If a blind yes is all is needed here, it's OK. Then Eric should not address this issue at all. Module registration is not required, too. But, to be honest, I think the response Eric got is a lot more friendly than what I got about a question regarding to CGI.pm. Surely a simple patch that shouldn't make any problem should not address any discussion, but should it not address any attention to the author? Of course, it's the author's decision to pay attention to me or not. I shouldn't complain about that. -- Best regards, imacat ^_*' [EMAIL PROTECTED] PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug pgpgCl8dwzmtc.pgp Description: PGP signature
Re: RFC: Getopt::Modern
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 23:40]:
The point is that the community can be unnecessarily combative
and ugly, a point which to my eyes you have helped illustrate.
Yes, I was rude. At first I was frustrated after trying to find
information about Erics proposal other than this fixes
everything thats wrong with Getopt::Long, then flustered when
I found (to caricature the situation) that I want to *all* that
*effort* only to find *this*? The combination of well,
effectively insubstantial hype was what set the mood.
It is not particularly respectful to make your audience jump
through hoops because you cant contain your urge to hype
something; nor was the hyperbole warranted.
In any case, I should have detached and let it slide, instead of
getting fixated on a sense of obligation to follow up after I
voiced my initial frustration.
In fact, all the heat generated seems kind of comical now that I
look at it, because Im not trying to keep Eric from putting this
on CPAN at all. Even in the curmodgeonly view, theres no
appreciable harm that can result from adding another @ARGV parser
to CPAN, seeing as theres already a pile of them there, and
seeing how most people happily use the common ones and some
happily use obscure ones.
On the other hand, Eric *did* get a lot of feedback.
What is the sound of one hand clapping?
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
Re: RFC: Getopt::Modern
Eric Wilhelm wrote: Code: http://scratchcomputing.com/svn/Getopt-Modern/trunk/ English: http://scratchcomputing.com/developers/Getopt-Modern/ I tried following the online slide show but it failed here: http://scratchcomputing.com/developers/Getopt-Modern/slides/text2.html with a 404 Not Found error. jimk
Re: RFC: Getopt::Modern
On Thu, 16 Jun 2005 11:21:04 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
* lacks predictable behaviour
I fail to see your point here. Options are handled from left to
right, which makes perfect sense.
I have watched the on-line slide. The slide said:
* lacks predictable behaviour
* users are too unpredictable
GetOptions(
'foo' = \$foo,
'no-foo' = sub {$foo = 0},
);
print $foo\n;
$ a_program --foo --no-foo
0
$ a_program --no-foo --foo
1
To Eric,
I'm not against new modules at all. I'm also new here. But I
really can't see the point here. I though that is the desired behavior,
isn't it? What do you think is right on that example? Croak? Return
1 on both cases? Return 0 on both cases?
--
imacat ^_*'
[EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt
Tavern IMACAT's http://www.imacat.idv.tw/
Woman's Voice http://www.wov.idv.tw/
TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug
pgpJDTGeGTTa5.pgp
Description: PGP signature
RE: RFC: Getopt::Modern
Indeed, the example seems to contradict the text:
The behaviour shown is entirely predictable. I'd also argue that it's
desirable, although I guess that it's subjective.
-Original Message-
From: imacat [mailto:[EMAIL PROTECTED]
Sent: Thursday, June 16, 2005 11:01 AM
To: Perl Module Authors
Subject: Re: RFC: Getopt::Modern
On Thu, 16 Jun 2005 11:21:04 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
* lacks predictable behaviour
I fail to see your point here. Options are handled from left to
right, which makes perfect sense.
I have watched the on-line slide. The slide said:
* lacks predictable behaviour
* users are too unpredictable
GetOptions(
'foo' = \$foo,
'no-foo' = sub {$foo = 0},
);
print $foo\n;
$ a_program --foo --no-foo
0
$ a_program --no-foo --foo
1
To Eric,
I'm not against new modules at all. I'm also new here. But I
really can't see the point here. I though that is the desired
behavior,
isn't it? What do you think is right on that example? Croak? Return
1 on both cases? Return 0 on both cases?
--
imacat ^_*'
[EMAIL PROTECTED]
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt
Tavern IMACAT's http://www.imacat.idv.tw/
Woman's Voice http://www.wov.idv.tw/
TLUG List Manager http://www.linux.org.tw/mailman/listinfo/tlug
Re: RFC: Getopt::Modern
Order is significant because of the shell. If you commonly use a program with option --foo, then you often decide to make an alias for the program that includes that option. If order is significant, then you can call the alias and add the --no-foo option to get a different effect without have to go around your shell alias. Some programs like 'less' even allow you to put options into an environment variable, then let command line options override the variable. -Lee Date: Thu, 16 Jun 2005 14:35:52 -0700 From: Eric Wilhelm [EMAIL PROTECTED] To: module-authors@perl.org Subject: Re: RFC: Getopt::Modern User-Agent: KMail/1.7.1 X-MIME-Autoconverted: from quoted-printable to 8bit by defiant.dfw.nostrum.com id j5GLYjS20646 # The following was supposedly scribed by # A. Pagaltzis # on Thursday 16 June 2005 05:00 am: As for the ???'foo!' = \$foo??? thing I misunderstood your example (I thought you were pointing out a bug or ommission) because I *expect* the exact behaviour that you say is ???non-strict???. This seems to be a common reaction? Why? You wouldn't say --foo --no-foo if you just meant --no-foo Would you? It also seems to be a programmerly reaction, which leads me to the thought that maybe the name I want is Getopt::User because the primary design goal is to present the user with predictable option processing. Please see this essay http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt --Eric -- Minimum wage help gives you minimum service. -- David Schomer - http://scratchcomputing.com - -- Lee Eakin - [EMAIL PROTECTED] With sufficient thrust, pigs fly just fine. -- RFC 1925
Re: RFC: Getopt::Modern
# The following was supposedly scribed by # Johan Vromans # on Thursday 16 June 2005 02:21 am: [Quoting Eric Wilhelm, on June 15 2005, 16:58, in RFC: Getopt::Modern] As the author and maintainer of Getopt::Long I would be very interested to know what exactly your problems are. I would love for Getopt::Long to be able to behave according to this design, but I don't believe that it's feasible (unless it gets done with BEGIN...require($one_or_the_other). In other words, I set out to redesign both the architecture and the specification. If you're interested in refactoring Getopt::Long, I would be happy to help. What design? - (roughly) trunk/data/notes/why_rebuild_getopt-long.txt Some points from your slides: G::L is actively maintained, which I think is more important. And I commend you for it. I do often try to contact the author before starting such patch/rewrite work and usually don't get an answer. In this case, the rewrite was bound to be an independent exercise even if the end result is ultimately a patch (which it most-likely can't be.) * 15 years old What do you mean by that? Perl is 18 years old. C is even older. re-arranging slightly * too flexible Interesting point. I think G::L follows Perl in TIMTOWTDI. Most flexibility has been added on user request. These two things go together to yield the third here. Sorry if that wasn't clear. 15 years * n requests/year = 15*n degrees of flexibility = unpredictable * lacks predictable behaviour I fail to see your point here. Options are handled from left to right, which makes perfect sense. To the computer, not the user. Please see below. * wants to deal with an API This is provided by the OO API of G::L. Besides, a single function is also an API. True, but Getoptions() currently contains all of the expertness of G::L, which means that other modules cannot learn anything about the options (such as when Getopt::Helpful would like to know if these are simple/float/list/hash, etc options without re-implementing G::L's parsing.) If you tear it apart and put it back together in pieces, it would have the API of which I speak. * not super-configurable Wow! Ain't this begging for a simple 2-line wrapper module around G:L instead of re-inventing the wheel? No. If it involves typing @main::ARGV, something is wrong. * Arguments in bundles never looked right anyway I think this is where the personal / religious feelings kick in. Could be. Is this something that can/should be resolved with yet-another-option? * users do not (and should not have to) understand the programmer's problems I fail to see your point. Can you elaborate? Please see the 'data/notes/why_order_matters.txt' in the repository. * multi-pass support I think this is possibly the only real improvement to G::L. And, (from my reading of G::L) one that requires a fundamental restructuring of the code. Personally, I doubt wheter this validates yet another Getopt:: module (unless you have fun writing it, which is important as well!) I would love to just make this be Getopt::Long, but I rather doubt that it would be possible (or maybe even desirable) for it to be reverse-compatible with 15 years worth of code (except in the (we're-really-just-faking-it) case of the aforementioned BEGIN hack.) --Eric -- Peer's Law: The solution to the problem changes the problem. - http://scratchcomputing.com -
Re: RFC: Getopt::Modern
Eric Wilhelm wrote: Ok. Here's one edge-case which probably involves somebody smart enough to not get stuck in it. Is this really a good argument for perplexing the user the other 99% of the time? It seems to me that that situation is far more than 1%, more like 99%, of the times *when both --foo and --no-foo options are specified*. We don't care about the 99% of the time when it's only --foo or only --no-foo (or neither), because there's no confusion there. I've read your essay, but I still have no idea what sort of non-programmerly users you're writing this for. First of all, no one who's not at least a little programmerly is going to be using command-line options in the first place. Second, what sort of user is going to be typing --foo --no-foo (or --no-foo --foo)? If I did run into that sort of user I'd be mystified as to what they intended (and your essay didn't help me with guessing), and like Ovid I'd say the best thing to do is die with an error message. -- Keith C. Ivey [EMAIL PROTECTED] Washington, DC
Re: RFC: Getopt::Modern
On Jun 16, 2005, at 4:56 PM, Ovid wrote: I'm sorry, while I certainly won't argue that there is necessarily a need for a new module here, I will argue that the order of arguments shouldn't matter. Asking for foo and then asking for no foo doesn't make a lick of sense to me. What does that mean? That we are in some mysterious heisenstate where the it's neither foo and not foo? In following the principle of least surprise, the user of a program should not have to worry about issues like this and I would prefer that contradictory command line arguments cause the program to halt with a loud what the hell do you mean? For a counterexample, please see the -f and -i options to /bin/rm. Many people, myself included, have found it exceptionally useful that the final switch takes precedence, because then we can do things like alias ls ls -i and still be able to use the -f switch when we need to. -Ken
Re: RFC: Getopt::Modern
On Jun 16, 2005, at 10:12 PM, Eric Wilhelm wrote: Do you mean to say that 99% of the time (when --foo and --no-foo are both present) that it is because somebody has an alias with a --foo flag written into it? Restated: if we counted 100 times that the user used these flags together, 99 of them would be due to an alias? Surely not. In my experience it's more like 99.999%. And I can't actually remember seeing a legit case of the 0.001% coming out of my fingers, but I'm throwing it in there as a bone. The alias thingy is just an example of people setting up their preferred default behavior and then allowing themselves to alter that in occasional specific cases. It's a common idiom for lots of commands that take flags. -Ken
Re: RFC: Getopt::Modern
# The following was supposedly scribed by # Ken Williams # on Thursday 16 June 2005 08:42 pm: In my experience it's more like 99.999%. And I can't actually remember seeing a legit case of the 0.001% coming out of my fingers, but I'm throwing it in there as a bone. The alias thingy is just an example of people setting up their preferred default behavior and then allowing themselves to alter that in occasional specific cases. It's a common idiom for lots of commands that take flags. Ok, and maybe I showing my age here, but is *this* where the negated-options thing comes from? I.E. is this the historic (and entire) reason for having the 'foo!' syntax in Getopt::Long? If so, is that why there is so much resistance to evaluating in anything besides command-line order? If this is the case, then the cat to be skinned is a couple of steps to the left, since an alias override is a different beast than a config-file override (and not having any way to tell them apart isn't going to help either.) --Eric -- Introducing change is like pulling off a bandage: the pain is a memory almost as soon as you feel it. -- Paul Graham - http://scratchcomputing.com -
Re: RFC: Getopt::Modern
You should take a look at C's manpage getopt_long(3). The use of shell aliasing for the default options is very common on the modern Linux boxes. Most Linux distributions shipped with default shell aliasing, and most your so-called primitive users won't even notice that. When you type cp it is really expended to cp -i. Some way to disable that behavior is absolutely required. Users need a way to override the systems' default or her/his own default. They are not required to know the detail of shell aliasing. They just want to set the options they needed and see the result. This is not the programmers' view. It's the users' view. I have read your why_order_matters.txt. Yes, users can backspace and remove the -vvv. But from my experience moving cursor to a specific position is no easy thing on slow, remote machines. Adding --no-v at the tail can save my life. And what if that command is in fact aliased? Do I have to unalasing first before lowering down the verbose level? Are you intended to tell this unaliasing first to your so-called primitive users? If there are applications equipped with that Getopt::Modern, I would avoid using them since I have to unalias first in order to override the default. I would not suggest my users to use them, too, since I have to teach them to unalias first. That unalias first is definitly not the users' view. I know some shells don't have aliasing, like command.com, cmd.exe or explorer.exe on MS-Win32 boxes. The MS-Win32 distributor won't ship any default options by aliasing at all. Are the users on MS-Win32 boxes what you mean here? But even on those shells when I wrote a cp.bat to replace cp.exe to set my default arguments, I still need a way to override my own default. Of course I can still parse the arguments of cp.bat myself and remove -vvv from the default. But if I have to do so, what do I need Getopt::Modern for? Not allowing overriding the default is the system administrators' view, or the programmers' view, but definitely not the users' view. Not personal, but this is the only clear point in all the problems you mentioned against Getopt::Long. Other points stated in your slide are ambiguous. On Thu, 16 Jun 2005 15:07:40 -0700 Eric Wilhelm [EMAIL PROTECTED] wrote: # The following was supposedly scribed by # Lee Eakin # on Thursday 16 June 2005 02:59 pm: Order is significant because of the shell. ?f you commonly use a program with option --foo, then you often decide to make an alias for the program that includes that option. ?f order is significant, then you can call the alias and add the --no-foo option to get a different effect without have to go around your shell alias. Ok. Here's one edge-case which probably involves somebody smart enough to not get stuck in it. Is this really a good argument for perplexing the user the other 99% of the time? Furthermore, would --de-foo not satisfy this (occasional) need? --Eric -- Everything goes wrong all at once. -- Quantized Revision of Murphy's Law - http://scratchcomputing.com - -- Best regards, imacat ^_*' [EMAIL PROTECTED] PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt Woman's Voice News: http://www.wov.idv.tw/ Tavern IMACAT's: http://www.imacat.idv.tw/ TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug pgp3ptCTTsFBE.pgp Description: PGP signature
Re: RFC: Getopt::Modern
Eric Wilhelm wrote: If this is the case, then the cat to be skinned is a couple of steps to the left, since an alias override is a different beast than a config-file override (and not having any way to tell them apart isn't going to help either.) I don't see what makes them so different -- for this discussion, who cares whether the options are saved in a config file or an alias? And I still don't understand what this common situation is in which you see users typing --foo --no-foo or --no-foo --foo, or what you think they mean by it. The only reason I can imagine it maybe happening would be if because of frequent use you have a finger macro for command --foo or command --no-foo, and have already typed it before you realize that this time you want the opposite of your usual option. Then rather than backspacing you might type the other option. But in that case the desired behavior would be exactly the same as the desired behavior for the alias override case -- for the last option to take precedence. -- Keith C. Ivey [EMAIL PROTECTED] Washington, DC
RFC: Getopt::Modern
Code: http://scratchcomputing.com/svn/Getopt-Modern/trunk/ English: http://scratchcomputing.com/developers/Getopt-Modern/ This is essentially a replacement/update for Getopt::Long. Any suggestions on names? Getopt::Strict Getopt::Predictable Seems like Modern would wear off after a while. Thanks, Eric P.S. I still need to write the documentation. Just pretend that it reads like the first half of perldoc Getopt::Long (I've really only added a dash of strictness, a pinch of thrifty clarity, and a teaspoon of API.) -- Left to themselves, things tend to go from bad to worse. -- Murphy's Corollary - http://scratchcomputing.com -
Re: RFC: Getopt::Modern
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-16 02:05]:
English:
http://scratchcomputing.com/developers/Getopt-Modern/
Your presentation gets about two slides in before it chokes on
404s.
I looked at the code and didnt see much that warranted a new
module and an OO API.
The example you show on your first slide is easily fixed by
simply saying
'foo!' = \$foo,
in which case Getopt::Long will provide the necessary behaviour
for a --no-foo option by itself. Of course that might be just
an example.
This is essentially a replacement/update for Getopt::Long.
You need to evangelize it less haphazardly if you want to
convince people.
Right now I have no idea why Id use your module over ::Long
(which is in core, a significant advantage) or why a fork was the
better course of action over patches to ::Long.
If you really want it to succeed, it needs to be *much* better
than the established way of doing things. (Right now, it doesnt
seem like it is; but I cant make an informed call now, can I?)
Any suggestions on names?
Getopt::Strict
Getopt::Predictable
Seems like Modern would wear off after a while.
Indeed, ::Modern is a poor choice. Im afraid I have no better
ideas since I have no idea about the distinguishing/defining
aspects of your module.
P.S. I still need to write the documentation. Just pretend
that it reads like the first half of perldoc Getopt::Long
(I've really only added a dash of strictness, a pinch of
thrifty clarity, and a teaspoon of API.)
Well, thats kind of a problem, as you see. :-)
*Something*, anything, is better than nothing. First draft
documentation need not be well-written or exhaustive; but it must
give at least a vaguely comprehensive overview and the general
idea, otherwise the code might as well not exist. Write at least
a few example scripts demonstrating a sufficiently large portion
of the API. (I tried to read the test suite for some example
code, but that wasnt much help.) *Something*, anything, is
better than nothing.
It might cure cancer or solve world hunger; if noone knows what
it does or how to use it, its of little value.
Regards,
--
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(,$\/, )[defined wantarray]/e;$1};
Just-another-Perl-hacker;
