Re: RFC: Getopt::Modern

[Sam Vilain]

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 coördinating 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

[A. Pagaltzis]

* 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 don’t see why it is “ancient” instead of “sensible.” You mean
that you think it’s not a good fit for this particular case; and
I’ve already said at least twice that the exemplified command
line interface to Eric’s 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]

"A. Pagaltzis" <[EMAIL PROTECTED]> writes:

>> Something like ++ instead of --.
>
> I think thatʼs ugly. Iʼd 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

[A. Pagaltzis]

* 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
don’t know about anyone else here, but if I saw that I could tell
this hypothetical shopping application that I want “--un-fish”,
I’d have no idea what that’s 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 that’s ugly. I’d 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”
you’re writing on the command line — something that can be added
as an afterthought, like the subclause you’re reading right now.

For this hypothetical shopping application I’d 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-default fish,meat,fruit”. With the tripple dash, I’d call
it something else (though I don’t quite know what), but it’d work
the same way.

Regards,
-- 
Aristotle
“Like punning, programming is a play on words.”
   – Alan J. Perlis, “Epigrams in Programming”

Re: RFC: Getopt::Modern

[Johan Vromans]

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.

Something like ++ instead of --.

-- Johan

Re: RFC: Getopt::Modern

[Johan Vromans]

Eric Wilhelm <[EMAIL PROTECTED]> writes:

> It's about a package modifying a global variable deep inside the
> core of its functionality.

It's clearly defined to do so, and all Getopt:: modules operate that
way.

It's even *IMPORTANT* that @ARGV gets modified, when the next thing
you want to do is something like 

  while ( <> ) {
...
  }

There's no point in introducing extra overhead (and typing) by
explicitly having to pass a ref to @ARGV. 

But I agree that it sometimes would be nice to be able to pass a ref
instead of having to localise @ARGV. 

-- Johan

Re: RFC: Getopt::Modern

[Johan Vromans]

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

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

[Johan Vromans]

Eric Wilhelm <[EMAIL PROTECTED]> writes:

> What I've learned about this is that:
>
> 1.  Historically, "--no-" was intended to reset hard-coded and 
> config-file options.

Wrong. --foo sets flag foo to true, --no-foo sets flag foo to false.
Nothing more, nothing less.

-- Johan

Re: RFC: Getopt::Modern

[Johan Vromans]

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]

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

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

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

[David Landgren]

Eric Wilhelm wrote:

# The following was supposedly scribed by
# A. Pagaltzis
# on Friday 17 June 2005 03:05 am:



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.



Ok.  Then we agree :-)  (can you tell?)

Uh.  so everybody is emotional about '--no-'.  Good.  I'll leave that 
behaving the way it has.


I wouldn't say emotional, People have simply been trying to press you 
for a more convincing explanation as to why the current situation is 
broken. I think on the whole, people are not convinced :)


David

Re: RFC: Getopt::Modern

[Johan Vromans]

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

[Johan Vromans]

"A. Pagaltzis" <[EMAIL PROTECTED]> writes:

> That’s not trivial, period. Any solution will have to be pretty
> complex if it’s supposed to handle this – especially if you want
> the user to be able to override only some defaults, but not
> others. I’m not sure that any form of command line will be
> anything other than craptacular for a job like this.

To which I'd like to add: If you want to take into account that
initial values for options can come from several sources, like config
files (several config files!), environment variables,
programmatically, derived from the name the program was called with,
and also that a command line option may specify a different config
file, or defeat any config files, then you may begin to see the
complexity of the matter. And that's why Getopt::Long only parses
command lines, nothing else...

I'd be one of the first to support a decent standard on this matter,
but unfortunately there is none. On the bright side, everyone seems to
agree more or less on how it should be done, so let's stick to that
"fuzzy" standard.

If the need is there to introduce a new way of doing it, I'd strongly
suggest to select a distinctive form so users know what to expect.

-- Johan

Re: RFC: Getopt::Modern

[Johan Vromans]

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

[Martyn J. Pearce]

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

[Johan Vromans]

> 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

[Johan Vromans]

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

[Johan Vromans]

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

[A. Pagaltzis]

* 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 Eric’s proposal other than “this fixes
everything that’s 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 can’t 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 I’m not trying to keep Eric from putting this
on CPAN at all. Even in the curmodgeonly view, there’s no
appreciable harm that can result from adding another @ARGV parser
to CPAN, seeing as there’s 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

[imacat]

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

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

[Ken Williams]

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

[Austin Schutz]

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 ? :-)
> 
> 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

[A. Pagaltzis]

* Austin Schutz <[EMAIL PROTECTED]> [2005-06-17 22:45]:
> Imagine this is Eric's first try at publishing a module.

Then what is ? :-)

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

[Eric Wilhelm]

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

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

[Ken Williams]

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

[A. Pagaltzis]

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

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;

Re: RFC: Getopt::Modern

[Ovid]

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

[A. Pagaltzis]

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

That’s not trivial, period. Any solution will have to be pretty
complex if it’s supposed to handle this – especially if you want
the user to be able to override only some defaults, but not
others. I’m 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.

That’s 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

[imacat]

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

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

[A. Pagaltzis]

* 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 can’t 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

[A. Pagaltzis]

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

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

# The following was supposedly scribed by
# A. Pagaltzis
# on Friday 17 June 2005 03:05 am:

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

Ok.  Then we agree :-)  (can you tell?)

Uh.  so everybody is emotional about '--no-'.  Good.  I'll leave that 
behaving the way it has.

Using '--start-' is maybe not the best choice (mostly for length.)

In any case.  How does G::L evaluate in precedence order?  That's why 
I'm writing G::?

There are other useful situations for controlling the order.  We just 
haven't covered them yet.

--Eric
-- 
"Everything goes wrong all at once."
--Quantized Revision of Murphy's Law
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

[imacat]

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

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

[Eric Wilhelm]

# 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

[Eric Wilhelm]

# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 08:14 am:

>Finally, I must say, your web site makes me sad.
>
>There's nothing wrong with willing to write your own Getopt:: module,
>but if you want to motivate this by mere criticizing other people's
>modules you'd better use good arguments. And it would be nice to
>communicate the arguments with the other party first.

Please don't take so much offense.  This is just a piece of code that I 
felt I needed to write in order to facilitate Getopt::Helpful.

Because I had originally built that as a wrapper around Getopt::Long, I 
had a laundry-list of what didn't work.  Unsaid are all of the things 
about how great G::L is (sorry, I see this as obvious.)  I'm not out to 
fix what works, only what doesn't.

If I thought that I needed to replace Getopt::Long by getting the rest 
of the world to use my module, I would have done things differently but 
that was not my goal.

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.  
Do you have a project page for your recent work?  Maybe I could find a 
way to work it in if I saw what you had thus far.

--Eric
-- 
Hot dogs:  just another condiment.
--Heart-attack Man
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

[Eric Wilhelm]

# The following was supposedly scribed by
# Johan Vromans
# on Friday 17 June 2005 01:03 am:

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

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.

>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.  If arg1 and arg2 are 
arguments and foo is a simple option, then it arg1 and arg2 are simply 
passed through.  If they needed to be processed in context, foo 
wouldn't be a simple option.  That's just my take on it.

--Eric
-- 
"...the bourgeoisie were hated from both ends: by the proles, because
they had all the money, and by the intelligentsia, because of their
tendency to spend it on lawn ornaments."
--Neal Stephenson
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

[Eric Wilhelm]

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

RE: RFC: Getopt::Modern

[Orton, Yves]

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

[Johan Vromans]

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

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

> If you tear it apart and put it back together in pieces, 

How I do it, is my responsibility.

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

> Could be.  Is this something that can/should be resolved with 
> yet-another-option?

If you don't like it, don't use it. Why prevent others from using
something they find useful?

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

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.

Finally, I must say, your web site makes me sad.

There's nothing wrong with willing to write your own Getopt:: module,
but if you want to motivate this by mere criticizing other people's
modules you'd better use good arguments. And it would be nice to
communicate the arguments with the other party first.

>From the site:

  Everything you need and nothing you don't.

Thank you, Eric, for saving the world by telling us what we
need and what we don't.

  I started writing this module because I was trying to use
  Getopt::Long as if it had an API and it doesn't.

That's okay. Reading the docs would have helped, though.

  Things like juggling @main::ARGV just had to stop.

That's a personal opinion. Please address P5P if you don't like this
language feature.

  There's a few other "features" in Getopt::Long that you may not have
  even discovered yet. 

Please mention the "features" that are not documented (so I can
fix the code or improve the documentation).

  Needless to say, we don't need those.

Again, a personal statement. You may not need them, others do.

Just like "Perl can do SystemV message queues and semaphores. Needless
to say, we don't need those. So let's write our own Perl clone that
doesn't have this facility." Yuck.

-- Johan

Re: RFC: Getopt::Modern

[Johan Vromans]

[Quoting Ken Williams, on June 17 2005, 06:46, in "Re: RFC:  Getopt::Mo"]
> > 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.

In the 15 years I've been developing and maintaining Getopt::Long I've
spoken many people with very specific (even weird) wishes. That's why
I mentioned a couple of times that command line options processing is
almost a religious issue.

Many people I talked to found what they needed in Getopt::Long, and
sometimes I added their suggestions for them. The relatively few
people that didn't see their wishes granted developped their own
Getopt:: modules. I see no problem with that. I think that's part of
the freedom that the world of free software provides.

As for the naming, I'd suggest Getopt::Personal::EWilhelm, since that
indicates clearly what it is, as I understand it from the discussion.

-- Johan

Re: RFC: Getopt::Modern

[Sean Quinlan]

On Thu, 2005-06-16 at 20:12 -0700, Eric Wilhelm wrote:
> # The following was supposedly scribed by
> # Keith Ivey
> # on Thursday 16 June 2005 07:46 pm:
> 
> >> 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*.  
> 
> 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?

Yes. I've _never_ used a program where I found myself using both --foo
and --no-foo on the command line unless I was over-riding an alias. A
straw poll of a couple others in the lab indicated that they also have
never had occasion (at least that they recall) to type both --foo and
--no-foo. I also can't think of a single program where that would be
called for in normal use. IMHO if I wrote a program that encouraged that
sort of use, I would assume I had poorly designed it and try to fix that
issue.

And as another point, I doubt the vast majority of people who are using
command line interfaces to complex programs are _average_ users. If I
have a complex program that users who are not experienced or comfortable
with complex sets of command line options need to use, I either create a
GUI interface of some kind, or set aup a couple system aliases with the
most common options specified.

> >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
> 
> If it's not clear what '--no-foo --foo' means then it wouldn't impact 
> you either way I write it?
> 
> 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.

And is why, if I want a user to set a value, I use 'foo=i' or 'foo=s' or
such. That seems far more natural to me, and has worked quite well in my
experience. What user, who might be confused by --foo --no-foo handling,
is going to even _know_ that --no-foo is an option?!?

-- 
Sean Quinlan <[EMAIL PROTECTED]>
Massachusetts General Hospital

Re: RFC: Getopt::Modern

[Ken Williams]

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

[Ken Williams]

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

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2005-06-17 01:35]:
> >I don’t 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? I’m asking what this need is. I want to
know which things we are trying to achieve. If we don’t 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 didn’t see anything new that hasn’t 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 I’ve 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 I’ve 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 it’s 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 can’t tell what option comes from an alias and which
doesn’t. Even if you could, that wouldn’t 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 you’re asking the “--no-foo” mechanism to do for you it
neither something it’s meant to do nor something it’s a good
literary choice for.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;

Re: RFC: Getopt::Modern

[imacat]

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

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

[Johan Vromans]

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

[Johan Vromans]

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

[Johan Vromans]

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

[Johan Vromans]

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

[Keith Ivey]

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

Re: RFC: Getopt::Modern

[imacat]

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

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

# 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

[Ken Williams]

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

[Ken Williams]

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

[Eric Wilhelm]

# The following was supposedly scribed by
# Keith Ivey
# on Thursday 16 June 2005 07:46 pm:

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

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.

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

No, I wasn't talking about that 99%.

>I've read your essay, but I still have no idea what sort of
>non-"programmerly" users you're writing this for. 

I used to be one of them.  Maybe that means that I had some programmer 
in me at the time, but it doesn't change fact that the in-command-order 
evaluation of options is a throwback.

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

no one?  zero?

>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

If it's not clear what '--no-foo --foo' means then it wouldn't impact 
you either way I write it?

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.

--Eric
-- 
"It is a mistake to allow any mechanical object to realize that you are 
in a hurry." 
  -- Ralph's Observation
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

[Keith Ivey]

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

[Eric Wilhelm]

# The following was supposedly scribed by
# A. Pagaltzis
# on Thursday 16 June 2005 03:37 pm:

>* Eric Wilhelm <[EMAIL PROTECTED]> [2005-06-16 23:40]:
>> >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?
>
>I don’t 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.

You said you "*expect* '--foo --no-foo' to make foo be zero".  I said 
'why would you say "--foo --no-foo" if what you really meant was 
"--no-foo"' (implying that the user had some sort of reason to say both 
and that the order should not be interpreted in the literal and 
aggravating way that seems to be the calling card of computers.)

Did you read the essay about why order doesn't matter?

--Eric
-- 
We who cut mere stones must always be envisioning cathedrals. 
-- Quarry worker's creed
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

[Ovid]

--- "A. Pagaltzis" <[EMAIL PROTECTED]> wrote:
> I donâ??t understand. If there was no need to be able to say
> â??--foo --no-fooâ??, then why do both exist?

I've seen plenty of code out there with both --quiet and --verbose
options.  They can be used to override default behavior which may be
triggered by config files or environment variables.

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

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2005-06-16 23:40]:
> >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?

I don’t understand. If there was no need to be able to say
“--foo --no-foo”, then why do both exist?

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;

Re: RFC: Getopt::Modern

[Eric Wilhelm]

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

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

# The following was supposedly scribed by
# Ovid
# on Thursday 16 June 2005 02:56 pm:

>>     I'm not against new modules at all.  I'm also new here.  But I
>>  What do you think is "right" on that example?  Croak?
>> Return
>> 1 on both cases?  Return 0 on both cases?
>

1

please see the "why_order_matters.txt"

>Asking for "foo" and then asking for "no foo" 
>doesn't make a lick of sense to me.  What does that mean?

How about:  "increment foo, but by-the-way start at zero"?

> cause the program to halt with a loud "what the hell do you mean?"

At which point the user says "what the hell do YOU mean!?" (and pounds 
the (what key do you pound when you're mad at a command-line program? 
(maybe rm $(which program

--Eric
-- 
"Because understanding simplicity is complicated." 
 -- Eric Raymond
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

[Eric Wilhelm]

# The following was supposedly scribed by
# Lee Eakin
# on Thursday 16 June 2005 02:59 pm:

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

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
-

Re: RFC: Getopt::Modern

[Lee Eakin]

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

[Ovid]

--- imacat <[EMAIL PROTECTED]> wrote:
> $ a_program --foo --no-foo
> 0
> 
> $ a_program --no-foo --foo
> 1
> 

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

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

Note that my preference appears different from the preferences others
have stated.  Of course, this is my *preference* and certainly not
something that I demand others accept.  So, in short, while there are
those who do not like Eric's way of handling arguments, I would argue
(ha!) that it's equally valid.

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

[Eric Wilhelm]

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

Re: RFC: Getopt::Modern

[A. Pagaltzis]

* Eric Wilhelm <[EMAIL PROTECTED]> [2005-06-16 03:55]:
> >Your presentation gets about two slides in before it chokes on
> >404s.
> 
> Sorry.  Bad batch publishing setup.  Works now.

Okay, after having seen your slides, I don’t see any requirement
that Getopt::Long doesn’t already fulfill with the right
configuration options. My scripts all start with

use Getopt::Long 2.24, qw(:config bundling no_ignore_case no_auto_abbrev);

and if you need precise ordering you can do that with
“require_order”; given “pass_through” that even enables you to do
multiple passes with a different set of switches on each of them.
And finally, passing closures, particularly one for the
pseudo-option “<>”, gives you ultimate flexibility in terms of
order-sensitive switches.

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

So basically this seems to come down to preferences. Calling the
module ::Modern certainly is a bit of a hyperbole in the face of
these facts…

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;

RE: RFC: Getopt::Modern

[Pearce, Martyn]

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

[imacat]

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

[Johan Vromans]

Hi Eric,

[Quoting Eric Wilhelm, on June 15 2005, 16:58, in "RFC:  Getopt::Modern"]
> This is essentially a replacement/update for Getopt::Long.

As the author and maintainer of Getopt::Long I would be very
interested to know what exactly your problems are.
15 years of experience has taught me that option handling is a very
personal and almost a religious thing, one of the reasons there are so
many Getopt:: modules on CPAN.

Some points from your slides:

* 15 years old
  What do you mean by that? Perl is 18 years old. C is even older.
  G::L is actively maintained, which I think is more important.

* too flexible
  Interesting point. I think G::L follows Perl in TIMTOWTDI.
  Most flexibility has been added on user request.

* lacks predictable behaviour
  I fail to see your point here. Options are handled from left to
  right, which makes perfect sense.

* wants a 2 stage approach
* wants to deal with an API
  This is provided by the OO API of G::L.
  Besides, a single function is also an API.

* not super-configurable
  Wow! Ain't this begging for a simple 2-line wrapper module around
  G:L instead of re-inventing the wheel?

* Getopt::Modern features
  Again, I think a simple wrapper around G::L will do the job.

* Arguments in bundles never looked right anyway
  I think this is where the personal / religious feelings kick in.

* users do not (and should not have to) understand the programmer's
  problems
  I fail to see your point. Can you elaborate?

* multi-pass support
  I think this is possibly the only real improvement to G::L.

Personally, I doubt wheter this validates yet another Getopt:: module
(unless you have fun writing it, which is important as well!)

As I said, option handling is a very personal and almost a religious
thing. There has never been a decent agreed upon standard how command
line options should be processed, although XPG and GNU did some
serious attempts. Getopt::Long tries to fulfill the Perl pragma
"making easy things easy, and hard things possible". 

So, again, as I said, I would be very interested to know what exactly
your problems with G::L are.

Regards,
Johan

Re: RFC: Getopt::Modern

[James E Keenan]

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

[Eric Wilhelm]

# The following was supposedly scribed by
# A. Pagaltzis
# on Wednesday 15 June 2005 05:50 pm:

>Your presentation gets about two slides in before it chokes on
>404s.

Sorry.  Bad batch publishing setup.  Works now.

>I looked at the code and didn’t see much that warranted a new
>module and an OO API.

Right.  I'll keep working and post again in about a week when things 
make more sense.

--Eric
-- 
The opinions expressed in this e-mail were randomly generated by the 
computer and do not necessarily reflect the views of its owner. 
   -- Management
-
http://scratchcomputing.com
-

Re: RFC: Getopt::Modern

[A. Pagaltzis]

* 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 didn’t 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 I’d 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 doesn’t
seem like it is; but I can’t 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. I’m 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, that’s 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 wasn’t 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, it’s of little value.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;