RFC: Getopt::Modern

Code:
  http://scratchcomputing.com/svn/Getopt-Modern/trunk/

English:
  http://scratchcomputing.com/developers/Getopt-Modern/

This is essentially a replacement/update for Getopt::Long.

Any suggestions on names?

  Getopt::Strict
  Getopt::Predictable

Seems like Modern would wear off after a while.

Thanks,
Eric

P.S.  I still need to write the documentation.  Just pretend that it 
reads like the first half of "perldoc Getopt::Long" (I've really only 
added a dash of strictness, a pinch of thrifty clarity, and a teaspoon 
of API.)
-- 
"Left to themselves, things tend to go from bad to worse." 
                                       -- Murphy's Corollary
---------------------------------------------
    http://scratchcomputing.com
---------------------------------------------
0
ewilhelm
6/15/2005 11:58:20 PM
perl.module-authors 1604 articles. 0 followers. Follow

90 Replies
531 Views

Similar Articles

[PageSpeed] 44
Get it on Google Play
Get it on Apple App Store

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
0
jkeen_via_google
6/16/2005 12:24:17 AM
* Eric Wilhelm <ewilhelm@sbcglobal.net> [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;
0
pagaltzis
6/16/2005 12:50:54 AM
# 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=E2=80=99t 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=20
make more sense.

=2D-Eric
=2D-=20
The opinions expressed in this e-mail were randomly generated by the=20
computer and do not necessarily reflect the views of its owner.=20
                                               -- Management
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/16/2005 1:47:56 AM
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
0
jvromans
6/16/2005 9:21:04 AM
--===[PGP/MIME_RFC2015]===42B14DB4.06A1===
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On Thu, 16 Jun 2005 11:21:04 +0200
Johan Vromans <jvromans@squirrel.nl> 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 ^_*'
imacat@mail.imacat.idv.tw
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

--===[PGP/MIME_RFC2015]===42B14DB4.06A1===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iEYEABECAAYFAkKxTbQACgkQi9gubzC5S1wfkgCfa2Z/Uh2QOVyS6gnlZPWveOfd
Nn0AoIlyBaFnp8J1mkfQPaseUIwGF3S5
=yInw
-----END PGP SIGNATURE-----
--===[PGP/MIME_RFC2015]===42B14DB4.06A1===--

0
imacat
6/16/2005 10:00:31 AM
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:imacat@mail.imacat.idv.tw] 
>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 <jvromans@squirrel.nl> 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 ^_*'
>imacat@mail.imacat.idv.tw
>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
>
0
martyn
6/16/2005 11:31:58 AM
* Eric Wilhelm <ewilhelm@sbcglobal.net> [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;
0
pagaltzis
6/16/2005 12:00:20 PM
# The following was supposedly scribed by
# A. Pagaltzis
# on Thursday 16 June 2005 05:00 am:

>As for the =E2=80=9C'foo!' =3D> \$foo=E2=80=9D 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 =E2=80=9Cnon-strict=E2=80=9D.

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=20
thought that maybe the name I want is Getopt::User because the primary=20
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_ma=
tters.txt

=2D-Eric
=2D-=20
Minimum wage help gives you minimum service.=20
                                            -- David Schomer
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/16/2005 9:35:52 PM
--- imacat <imacat@mail.imacat.idv.tw> wrote:
> $ a_program --foo --no-foo
> 0
> 
> $ a_program --no-foo --foo
> 1
> ============
<snip>
>     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/
0
publiustemp
6/16/2005 9:56:47 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.  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 <ewilhelm@sbcglobal.net>
> 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 - leakin@dfw.nostrum.com
 
    With sufficient thrust, pigs fly just fine.  -- RFC 1925
0
Leakin
6/16/2005 9:59:46 PM
# The following was supposedly scribed by
# Lee Eakin
# on Thursday 16 June 2005 02:59 pm:

>Order is significant because of the shell. =A0If you commonly use a
>program with option --foo, then you often decide to make an alias for
>the program that includes that option. =A0If 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=20
to not get stuck in it.  Is this really a good argument for perplexing=20
the user the other 99% of the time?

=46urthermore, would --de-foo not satisfy this (occasional) need?

=2D-Eric
=2D-=20
"Everything goes wrong all at once."=20
                       -- Quantized Revision of Murphy's Law
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/16/2005 10:07:40 PM
# The following was supposedly scribed by
# Ovid
# on Thursday 16 June 2005 02:56 pm:

>> =A0 =A0 I'm not against new modules at all. =A0I'm also new here. =A0But=
 I
>> =A0What do you think is "right" on that example? =A0Croak?
>> Return
>> 1 on both cases? =A0Return 0 on both cases?
>

1

please see the "why_order_matters.txt"

>Asking for "foo" and then asking for "no foo"=20
>doesn't make a lick of sense to me. =A0What 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=20
the (what key do you pound when you're mad at a command-line program?=20
(maybe rm $(which program)<ENTER>)))

=2D-Eric
=2D-=20
"Because understanding simplicity is complicated."=20
                                             -- Eric Raymond
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/16/2005 10:12:33 PM
# The following was supposedly scribed by
# Johan Vromans
# on Thursday 16 June 2005 02:21 am:

>[Quoting Eric Wilhelm, on June 15 2005, 16:58, in "RFC: 
> Getopt::Modern"]

>As the author and maintainer of Getopt::Long I would be very
>interested to know what exactly your problems are.

I would love for Getopt::Long to be able to behave according to this 
design, but I don't believe that it's feasible (unless it gets done 
with BEGIN...require($one_or_the_other).  In other words, I set out to 
redesign both the architecture and the specification.  If you're 
interested in refactoring Getopt::Long, I would be happy to help.

"What design?" -> (roughly) trunk/data/notes/why_rebuild_getopt-long.txt

>Some points from your slides:
>

>  G::L is actively maintained, which I think is more important.

And I commend you for it.  I do often try to contact the author before 
starting such patch/rewrite work and usually don't get an answer.  In 
this case, the rewrite was bound to be an independent exercise even if 
the end result is ultimately a patch (which it most-likely can't be.)

>* 15 years old
>  What do you mean by that? Perl is 18 years old. C is even older.
<re-arranging slightly>
>* too flexible
>  Interesting point. I think G::L follows Perl in TIMTOWTDI.
>  Most flexibility has been added on user request.

These two things go together to yield the third here.  Sorry if that 
wasn't clear.

15 years * n requests/year = 15*n degrees of flexibility = unpredictable

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

To the computer, not the user.  Please see below.

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

True, but Getoptions() currently contains all of the "expertness" of 
G::L, which means that other modules cannot learn anything about the 
options (such as when Getopt::Helpful would like to know if these are 
simple/float/list/hash, etc options without re-implementing G::L's 
parsing.)

If you tear it apart and put it back together in pieces, it would have 
the API of which I speak.

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

No.  If it involves typing @main::ARGV, something is wrong.

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

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

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

Please see the 'data/notes/why_order_matters.txt' in the repository.

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

And, (from my reading of G::L) one that requires a fundamental 
restructuring of the code.

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

I would love to just make this be Getopt::Long, but I rather doubt that 
it would be possible (or maybe even desirable) for it to be 
reverse-compatible with 15 years worth of code (except in the 
(we're-really-just-faking-it) case of the aforementioned BEGIN hack.)

--Eric
-- 
Peer's Law: The solution to the problem changes the problem.
---------------------------------------------
    http://scratchcomputing.com
---------------------------------------------
0
ewilhelm
6/16/2005 10:14:16 PM
* Eric Wilhelm <ewilhelm@sbcglobal.net> [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;
0
pagaltzis
6/16/2005 10:37:16 PM
--- "A. Pagaltzis" <pagaltzis@gmx.de> 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/
0
publiustemp
6/16/2005 10:40:41 PM
# The following was supposedly scribed by
# A. Pagaltzis
# on Thursday 16 June 2005 03:37 pm:

>* Eric Wilhelm <ewilhelm@sbcglobal.net> [2005-06-16 23:40]:
>> >As for the =E2=80=9C'foo!' =3D> \$foo=E2=80=9D thing I misunderstood yo=
ur
>> >example (I thought you were pointing out a bug or ommission)
>> >because I *expect* the exact behaviour that you say is
>> >=E2=80=9Cnon-strict=E2=80=9D.
>>
>> This seems to be a common reaction? =C2=A0Why?
>>
>> You wouldn't say
>>
>> =C2=A0 --foo --no-foo
>>
>> if you just meant
>>
>> =C2=A0 --no-foo
>>
>> Would you?
>
>I don=E2=80=99t understand. If there was no need to be able to say
>=E2=80=9C--foo --no-foo=E2=80=9D, 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=20
result should be the same.

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

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

=2D-Eric
=2D-=20
We who cut mere stones must always be envisioning cathedrals.=20
                                    -- Quarry worker's creed
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/16/2005 11:29:41 PM
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 <kcivey@cpcug.org>
Washington, DC
0
kcivey
6/17/2005 2:46:21 AM
# The following was supposedly scribed by
# Keith Ivey
# on Thursday 16 June 2005 07:46 pm:

>> Ok. =A0Here's one edge-case which probably involves somebody smart
>> enough to not get stuck in it. =A0Is 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*. =A0

Do you mean to say that 99% of the time (when --foo and --no-foo are=20
both present) that it is because somebody has an alias with a --foo=20
flag written into it?

Restated:  if we counted 100 times that the user used these flags=20
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.=20

I used to be one of them.  Maybe that means that I had some programmer=20
in me at the time, but it doesn't change fact that the in-command-order=20
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"=20
>(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=20
you either way I write it?

The purpose of a negated option is (in all of the usages that I have=20
seen) to reset any hard-coded or config-file variable.

=2D-Eric
=2D-=20
"It is a mistake to allow any mechanical object to realize that you are=20
in a hurry."=20
                                      -- Ralph's Observation
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/17/2005 3:12:21 AM
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

0
ken
6/17/2005 3:33:04 AM
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

0
ken
6/17/2005 3:42:06 AM
--===[PGP/MIME_RFC2015]===42B24B7B.64CD===
Content-Type: text/plain; charset="BIG5"
Content-Transfer-Encoding: 8bit

    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 <ewilhelm@sbcglobal.net> wrote:

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

--
Best regards,
imacat ^_*' <imacat@mail.imacat.idv.tw>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug

--===[PGP/MIME_RFC2015]===42B24B7B.64CD===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iEYEABECAAYFAkKyS3oACgkQi9gubzC5S1wX8ACeOLySwDUlRvssqM6+ukBOyKy9
RG8AoLAioj7LeK/yKfmI0k/GKHFB5lLz
=/5BS
-----END PGP SIGNATURE-----
--===[PGP/MIME_RFC2015]===42B24B7B.64CD===--

0
imacat
6/17/2005 4:03:19 AM
# 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%. =A0And 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. =A0It's a common idiom for lots of
> commands that take flags.

Ok, and maybe I showing my age here, but is *this* where the=20
negated-options thing comes from?  I.E. is this the historic (and=20
entire) reason for having the 'foo!' syntax in Getopt::Long?

If so, is that why there is so much resistance to evaluating in anything=20
besides command-line order?

If this is the case, then the cat to be skinned is a couple of steps to=20
the left, since an alias override is a different beast than a=20
config-file override (and not having any way to tell them apart isn't=20
going to help either.)

=2D-Eric
=2D-=20
Introducing change is like pulling off a bandage: the pain is a memory=20
almost as soon as you feel it.=20
                                              -- Paul Graham
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/17/2005 4:04:11 AM
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 <kcivey@cpcug.org>
Washington, DC
0
kcivey
6/17/2005 5:05:58 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/17/2005 7:53:04 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/17/2005 7:55:40 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/17/2005 8:03:26 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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


0
jvromans
6/17/2005 8:57:26 AM
--===[PGP/MIME_RFC2015]===42B29CFF.5E42===
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On Fri, 17 Jun 2005 10:57:26 +0200
Johan Vromans <jvromans@squirrel.nl> wrote:
> Eric Wilhelm <ewilhelm@sbcglobal.net> 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"  => \@opt_fishes,
  "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 ^_*' <imacat@mail.imacat.idv.tw>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug

--===[PGP/MIME_RFC2015]===42B29CFF.5E42===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iEYEABECAAYFAkKynP4ACgkQi9gubzC5S1zlMgCcD2zYleuFday6C1ATM+Ux5cqW
JRwAnirY6XTvYabot6uJhYzlDvs5jM4f
=B80b
-----END PGP SIGNATURE-----
--===[PGP/MIME_RFC2015]===42B29CFF.5E42===--

0
imacat
6/17/2005 9:51:11 AM
* Eric Wilhelm <ewilhelm@sbcglobal.net> [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  “-vvvvxyjk”.

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;
0
pagaltzis
6/17/2005 10:05:12 AM
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

0
ken
6/17/2005 11:42:44 AM
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

0
ken
6/17/2005 11:46:02 AM
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 <seanq@molbio.mgh.harvard.edu>
Massachusetts General Hospital

0
seanq
6/17/2005 1:57:00 PM
[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

0
jvromans
6/17/2005 2:16:08 PM
[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.

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

  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
0
jvromans
6/17/2005 3:14:33 PM
------_=_NextPart_001_01C57351.9E414BAA
Content-Type: text/plain

> [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 @ARGV=@ARGV;
   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

 


------_=_NextPart_001_01C57351.9E414BAA
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.2">
<TITLE>RE: RFC:  Getopt::Modern</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=3D2>&gt; [Quoting Eric Wilhelm, on June 16 2005, 15:14, =
in &quot;Re: RFC:&nbsp; </FONT>
<BR><FONT SIZE=3D2>&gt; Getopt::Mo&quot;]</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; 15 years * n requests/year =3D 15*n =
degrees of flexibility =3D </FONT>
<BR><FONT SIZE=3D2>&gt; unpredictable</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Hmm. I'd say</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt;&nbsp; 15 years * n requests/year * m happy =
users =3D reliability</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; which is as meaningless as your formula. =
</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; True, but Getoptions() currently contains =
all of the&nbsp; &quot;expertness&quot; of </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; G::L, which means that other modules =
cannot learn anything&nbsp; about the </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; options (such as when Getopt::Helpful =
would like to know if these are </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; simple/float/list/hash, etc options =
without re-implementing G::L's </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; parsing.)</FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; I can make this information available, if users =
would be interested.</FONT>
</P>

<P><FONT SIZE=3D2>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.</FONT></P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; If you tear it apart and put it back =
together in pieces, </FONT>
<BR><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; How I do it, is my responsibility.</FONT>
</P>

<P><FONT SIZE=3D2>Agreed. So long as the parse rules don't change =
bizarrely IMO publishing them should be sufficient.</FONT>
<BR><FONT SIZE=3D2>&nbsp;</FONT>
</P>

<P><FONT SIZE=3D2>&gt; &gt; &gt;* multi-pass support</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; &gt;&nbsp; I think this is possibly the =
only real improvement to G::L.</FONT>
<BR><FONT SIZE=3D2>&gt; &gt; </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; And, (from my reading of G::L) one that =
requires a fundamental </FONT>
<BR><FONT SIZE=3D2>&gt; &gt; restructuring of the code.</FONT>
</P>

<P><FONT SIZE=3D2>Unless I misunderstand what you mean by multipass =
here I think you are wrong:</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;{ </FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; local @ARGV=3D@ARGV;</FONT>
<BR><FONT SIZE=3D2>&nbsp;&nbsp; Getoptions(....);</FONT>
<BR><FONT SIZE=3D2>&nbsp;}</FONT>
<BR><FONT SIZE=3D2>&nbsp;Getoptions(....);</FONT>
</P>

<P><FONT SIZE=3D2>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.)</FONT></P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
<BR><FONT SIZE=3D2>&gt; I currently have two projects that address this =
issue: Getopt::Toolkit</FONT>
<BR><FONT SIZE=3D2>&gt; (which is based on Getopt::Long) and =
Getopt::Long version 3 (which is</FONT>
<BR><FONT SIZE=3D2>&gt; a complete redesign, a.k.a. Getopt::Long on =
steroids). Merging the two</FONT>
<BR><FONT SIZE=3D2>&gt; projects into a single new Getopt::Long version =
is somewhere on my</FONT>
<BR><FONT SIZE=3D2>&gt; TODO list. HOWEVER, since I highly appreciate =
my happy users, whatever</FONT>
<BR><FONT SIZE=3D2>&gt; comes out of the merge will be drop-in =
compatible with the current</FONT>
<BR><FONT SIZE=3D2>&gt; Getopt::Long. If this implies that you will not =
use it because it is</FONT>
<BR><FONT SIZE=3D2>&gt; too flexible, that's fine with me. One unhappy =
user against a zillion</FONT>
<BR><FONT SIZE=3D2>&gt; happy users.</FONT>
</P>

<P><FONT SIZE=3D2>OOOH. Maybe I shouldn't upload Getopt::Long::INI =
after all...</FONT>
</P>

<P><FONT SIZE=3D2>Anychance of some previews?</FONT>
</P>

<P><FONT SIZE=3D2>&gt; </FONT>
<BR><FONT SIZE=3D2>&gt; Finally, I must say, your web site makes me =
sad.</FONT>
</P>

<P><FONT SIZE=3D2>I can see why. Just so you know many of us hold G::L =
and yourself in high regard.</FONT>
</P>

<P><FONT SIZE=3D2>Cheers,</FONT>
<BR><FONT SIZE=3D2>Yves</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C57351.9E414BAA--
0
yves
6/17/2005 3:31:23 PM
# 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
---------------------------------------------
0
ewilhelm
6/17/2005 3:41:14 PM
# 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? =A0I.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=20
hard-coded or config-file defaults", then it shouldn't be evaluated in=20
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=20
arguments and foo is a simple option, then it arg1 and arg2 are simply=20
passed through.  If they needed to be processed in context, foo=20
wouldn't be a simple option.  That's just my take on it.

=2D-Eric
=2D-=20
"...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."
=2D-Neal Stephenson
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/17/2005 3:45:26 PM
* Johan Vromans <jvromans@squirrel.nl> [2005-06-17 17:20]:
> I can make this information available, if users would be
> interested.

Access to structured data is always nicer than implementing and
re-implemeting a parser for its serialized form.

So if it doesn’t take too much effort, it would be nice to have.
I might even need this at some point (I’m the current maintainer
of Getopt::Auto, though I must admit I have not done much to earn
the title yet).

> One unhappy user against a zillion happy users.

Since we’re at this: the one thing I still fall back to
Getopt::Std for is small scripts. I love Getopt::Long, but it
incurs a pretty high startup cost. Is there any chance you can
play some deferred compilation cards to make it go faster?

Of course, it’s kind of tricky for a module whose code all runs
exactly once, at program startup… maybe you can isolate the code
that implements various features and compile only those which are
actually requested/used? Of course, I have no idea what I’m
talking about, given that I haven’t taken even a cursory look at
the code.

I just thought I’d throw these out here while we’re at the topic,
before I get distracted by some other shiny ball.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
0
pagaltzis
6/17/2005 3:48:21 PM
# 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
---------------------------------------------
0
ewilhelm
6/17/2005 3:55:42 PM
# The following was supposedly scribed by
# imacat
# on Friday 17 June 2005 02:51 am:

>=A0 =A0 I did not notice the go_shop problem. =A0But I think it's trivial =
to
>solve that with Getopt::Long:
>
>my @conf_fishes =3D read_conf("fish"); =A0# get qw(trout)
>my @opt_fishes =3D qw();
>my $opt_nofish =3D 0;
>Getopt::Long::GetOptions(
>=A0 "fish=3Ds" =A0=3D> \@opt_fishes,
>=A0 "no-fish" =3D> \$opt_nofish,
>);
>@conf_fishes =3D qw() if $opt_nofish;
>my @fishes =3D (@conf_fishes, @opt_fishes);

Yes.  You can solve it.  It's not really trivial by the time you add=20
meats, cheeses, breads, and mustard though.  All of these things come=20
in many "flavors" and you might have a config file with your favorites=20
listed in it so that running "go_shop" with no arguments gives you a=20
routine trip, but you want to be able to change these things when you=20
get bored of the same-old options.

These 4 extra lines multiply by 5 items so far.

>=A0 =A0 Who said the variable to save the "no-fish" status has to be
>revelant with the "fish" variable anyway? =A0If 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=20
conventions which allow this to happen internally.  This saves the=20
author some code and gives the user a guaranteed consistent experience=20
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=20
convenience) reasons to keep its evaluation in command-line order.

What I'll probably end-up with is something like '--un-' performing the=20
above task of initializing internal values.

=2D-Eric
=2D-=20
"Everything goes wrong all at once."
=2D-Quantized Revision of Murphy's Law
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/17/2005 4:08:51 PM
--===[PGP/MIME_RFC2015]===42B2F675.5C21===
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On Fri, 17 Jun 2005 08:45:26 -0700
Eric Wilhelm <ewilhelm@sbcglobal.net> 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"  => \@opt_fishes,
  "no-fish" => \$opt_nofish,
);
@conf_fishes = qw() if $opt_nofish;
@fishes = (@conf_fishes, @opt_fishes);

--
Best regards,
imacat ^_*' <imacat@mail.imacat.idv.tw>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug

--===[PGP/MIME_RFC2015]===42B2F675.5C21===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iEYEABECAAYFAkKy9nUACgkQi9gubzC5S1wdGwCfc4Jy22H5BXq5xyGqPIkkpVii
cF4An39HGWIk2OBsY/AUqmm36uL/RrSW
=ytmO
-----END PGP SIGNATURE-----
--===[PGP/MIME_RFC2015]===42B2F675.5C21===--

0
imacat
6/17/2005 4:13:23 PM
# 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
>=E2=80=9C--no-verbose=E2=80=9D is a misnomer.
>
>It should be called =E2=80=9C--start-verbose=3D0=E2=80=9D, which indeed sh=
ould 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=20
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=20
I'm writing G::?

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

=2D-Eric
=2D-=20
"Everything goes wrong all at once."
=2D-Quantized Revision of Murphy's Law
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/17/2005 4:15:20 PM
# 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(\@ARGV));
}

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
---------------------------------------------
0
ewilhelm
6/17/2005 4:50:54 PM
* Eric Wilhelm <ewilhelm@sbcglobal.net> [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;
0
pagaltzis
6/17/2005 4:56:08 PM
* Eric Wilhelm <ewilhelm@sbcglobal.net> [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;
0
pagaltzis
6/17/2005 5:02:45 PM
--===[PGP/MIME_RFC2015]===42B303A9.404F===
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On Fri, 17 Jun 2005 09:08:51 -0700
Eric Wilhelm <ewilhelm@sbcglobal.net> 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 ^_*' <imacat@mail.imacat.idv.tw>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug

--===[PGP/MIME_RFC2015]===42B303A9.404F===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iEYEABECAAYFAkKzA6gACgkQi9gubzC5S1xLfQCeNzrFR6F+dBk+bg0gYgPpl5wy
KwIAn3u04IfpyURfoaDB9w9JtwaI9CcZ
=tCS8
-----END PGP SIGNATURE-----
--===[PGP/MIME_RFC2015]===42B303A9.404F===--

0
imacat
6/17/2005 5:09:05 PM
* Eric Wilhelm <ewilhelm@sbcglobal.net> [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;
0
pagaltzis
6/17/2005 5:18:14 PM
--- "A. Pagaltzis" <pagaltzis@gmx.de> 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/
0
publiustemp
6/17/2005 6:08:49 PM
* Ovid <publiustemp-moduleauthors@yahoo.com> [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;
0
pagaltzis
6/17/2005 7:13:44 PM
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:

> * Ovid <publiustemp-moduleauthors@yahoo.com> [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

0
ken
6/17/2005 8:07:27 PM
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 <publiustemp-moduleauthors@yahoo.com> [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
0
tex
6/17/2005 8:37:32 PM
# 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. =A0Eric, that was really obnoxious. =A0You 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=20
Congratulations and Clamoring new users".

This is a work in progress, and I was requesting (primarily) feedback on=20
the name (which I *know* is a dumb name (no.  Really.  The dumbest name=20
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=20
processing should behave.  So, I was trying to get to the bottom of the=20
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=20
config-file options.

2.  Since then, lots of people have been using it to override aliased=20
options (and as a fancy backspace key) (taking advantage of the=20
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=20
forward.

2.  More examples on the program-order evaluation, which appears to be=20
largely misunderstood.

3.  A clearly written set of design objectives, for my sake and the sake=20
of discussion.  Hell.  Maybe we'll even manage to hammer it into a=20
standard.


The trouble with open-source is that instead of cursing a black-box, I'm=20
able to dig through the code that's not doing what  I want and find=20
what needs to change.  So, I curse what needs fixing (of course this is=20
only what *I* see as needing fixing by definition I'm incapable of=20
seeing anything else) in there without stopping to say:

Wow!  This module really does some great stuff!  Isn't perl beautiful=20
and I'm really impressed at what Getopt::Long is so far.  Pats on the=20
back for everybody and smiles all around.  Now.  Let's get to work=20
because we can do better.

I am grateful to everyone who participated in the discussion.  Without=20
you, there wouldn't have been one.  And it was a good discussion. =20
Maybe I'll see a few of you at OSCON.  Send me an e-mail off-list and=20
I'll buy you a beer.

I do have strong opinions.  I also don't surrender them easily.  Of=20
course I think I'm great, but I never said I was better than anybody=20
else :-)

I'm not posting to seek approval.  Tell me this is the dumbest idea=20
you've ever heard and I'll be happy as long as you tell me why because=20
I will have learned something and my code (or at least someone's code)=20
will improve because of it.

Thanks,
Eric
=2D-=20
We who cut mere stones must always be envisioning cathedrals.
=2D-Quarry worker's creed
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/17/2005 8:53:20 PM
* Austin Schutz <tex@off.org> [2005-06-17 22:45]:
> Imagine this is Eric's first try at publishing a module.

Then what is <http://search.cpan.org/~ewilhelm/>? :-)

You could take at least a cursory look before making such
assumptions…

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
0
pagaltzis
6/17/2005 9:22:58 PM
On Fri, Jun 17, 2005 at 11:22:58PM +0200, A. Pagaltzis wrote:
> * Austin Schutz <tex@off.org> [2005-06-17 22:45]:
> > Imagine this is Eric's first try at publishing a module.
> 
> Then what is <http://search.cpan.org/~ewilhelm/>? :-)
> 
> You could take at least a cursory look before making such
> assumptions???
> 

	Was I assuming, or was I imagining? The point is that the
community can be unnecessarily combative and ugly, a point which to
my eyes you have helped illustrate.

	Austin
0
tex
6/17/2005 9:34:59 PM
A. Pagaltzis wrote:
> * Johan Vromans <jvromans@squirrel.nl> [2005-06-17 17:20]:
> 
>>I can make this information available, if users would be
>>interested.
> 
> 
> Access to structured data is always nicer than implementing and
> re-implemeting a parser for its serialized form.
> 
> So if it doesn’t take too much effort, it would be nice to have.
> I might even need this at some point  [...]

Being in the middle of writting option processing code[1] I'd like to 
throw a few ideas and comments out into the void...

First, order of commandline arguments does matter. The code I'm writting 
depends on this in several ways. First, it reads options from a rcfile 
much like the format used for svn, cvs, etc.

~/.modulebuildrc
* --verbose
install --uninst --noverbose

Command line options are parsed (passed thru to G::Long). Unless an 
option is present to disable rcfile processing, we process the rcfile. 
In the rcfile we have global options ('*'), and action specific options. 
When processing the rcfile we pass in to G::Long the options in a 
specific order: @global_rc_options, @action_specific_rc_options, 
@commandline_options. Notice in the example that globally the option 
--verbose is passed in, then only when executing the 'install' action 
verbosity is turned off. Finally, the commandline can be used to 
override any of these. If order didn't matter, there would be no way to 
override the defaults from the rcfile.

Another case is setting include directories. We want include directories 
searched in the order they appear on the commandline ('include-dirs=s@')

../Build --include-dirs /special/place --include-dirs /usr/include

A different order would cause problems if two different headers with the 
same name happen to exist in both locations.


I do wish Getopt::Long provided for more custom processing by providing 
incremental parsing: while ( $parser->next ) {...}. I also wish it 
accepted a string or argv like array and only used @ARGV as a default 
(and passed a reference to the option array to custom subs). Also, it'd 
be a bit more OO to provide the option to store parsed options 
internally, instead of storing the results in external variables.

I think there were more things I wished for when writing that module, 
but I'm too tired to think what they were right now.

Randy.

1. <http://thepierianspring.org/perl/Scratchpad.zip>
0
ml
6/17/2005 11:13:01 PM
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 <publiustemp-moduleauthors@yahoo.com> [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

0
ken
6/18/2005 12:26:46 AM
--===[PGP/MIME_RFC2015]===42B37CE9.5165===
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

On Fri, 17 Jun 2005 14:34:59 -0700
Austin Schutz <tex@off.org> 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 ^_*' <imacat@mail.imacat.idv.tw>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug

--===[PGP/MIME_RFC2015]===42B37CE9.5165===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iEYEABECAAYFAkKzfOgACgkQi9gubzC5S1yoGACgltPetrGeAwCop1eMQFfYzdDt
99AAn3Ru8VJvBsvXWA+fopGARjddHAZu
=KL9f
-----END PGP SIGNATURE-----
--===[PGP/MIME_RFC2015]===42B37CE9.5165===--

0
imacat
6/18/2005 1:46:26 AM
# The following was supposedly scribed by
# imacat
# on Friday 17 June 2005 06:46 pm:

> (I started to laugh at Johan's "Getopt::Personal::EWilhelm"),=20

Me too!

> Aristotle and I even figured out a simple
> solution to Eric's problem. =A0We have proved that Getopt::Long is not
> "unpredictable". =A0It is flexable to solve Eric's major problem.

Yes and No.  We'll see.

> Or maybe everybody here was doing wrong. =A0Should we just say,=20
> "go ahead, make your day", without even ...

No, this was (and is) a good discussion.  I've definitely learned that I=20
need to work on the problem more, and write my ideas more clearly=20
before I try to seek advice.  I just thought I could ask for a wee=20
suggestion about the name before it was done, but now it's clear to me=20
that I need to discover more about the problem that I'm trying to=20
solve.

I'm sure there's a lot of misunderstanding of what I'm after.  I don't=20
quite know myself, which is the main reason that I've not discussed the=20
module much until now.  Maybe I'm crazy.  I dunno.  I had decided to=20
take a step backward and look at option processing, why it is the way=20
it is, etc.  Part of this process involves reading Getopt::Long. =20
Anyway, did you ever look at a thing and think you've seen something=20
that's either completely new or completely crazy?

Of course, if it is really new, people will call you crazy.  But, then=20
again they'll do that even if your crazy!  Oh well.  I'll call it crazy=20
from now until I come up with something better or it goes away. =20
Writing code sure beats hanging out in a straightjacket, so I guess=20
I'll be writing code.

In any case, if anybody wants to comment or suggest while I'm working on=20
it, I'll be posting to this page as things progress:
  http://scratchcomputing.com/developers/Getopt-Crazy/

I'll probably go back to working on Getopt::Helpful for a few days to=20
try to figure out why this is better than what I was doing (I'm=20
guessing it mostly has to do with loading a config file.)  Don't worry,=20
I'm not planning to put Getopt::Helpful (or Getopt::Crazy) on CPAN for=20
a while yet.  They're both still sort of experiments.

Thanks,
Eric
=2D-=20
"It works better if you plug it in!"
=2D-Sattinger's Law
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/18/2005 2:53:38 AM
* Austin Schutz <tex@off.org> [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;
0
pagaltzis
6/18/2005 3:02:25 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/18/2005 8:39:41 AM
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.
0
fluffy
6/18/2005 8:40:29 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/18/2005 8:44:21 AM
> 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
0
jvromans
6/18/2005 8:46:02 AM
On Fri, Jun 17, 2005 at 05:48:21PM +0200, A. Pagaltzis wrote:
> * Johan Vromans <jvromans@squirrel.nl> [2005-06-17 17:20]:
> > I can make this information available, if users would be
> > interested.
> 
> Access to structured data is always nicer than implementing and
> re-implemeting a parser for its serialized form.
> 
> So if it doesn???t take too much effort, it would be nice to have.
> I might even need this at some point (I???m the current maintainer
> of Getopt::Auto, though I must admit I have not done much to earn
> the title yet).

Seconded.  I'm the "author" of Getopt::Plus, which is a wrapper around
Getopt::Long --- G::L does all the heavy lifting, thanks so much to Johan ---
that basically does auto-documentation and choose my own favourite config
options.  The two things that would make Getopt::Plus easier are

-)  Structured access to the option settings
-)  Option to pass in something other @ARGV to the arg-processing code.

thanks, Johan.

Mx.
0
fluffy
6/18/2005 8:55:57 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/18/2005 10:37:43 AM
"A. Pagaltzis" <pagaltzis@gmx.de> writes:

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

0
jvromans
6/18/2005 10:39:27 AM
"A. Pagaltzis" <pagaltzis@gmx.de> writes:

> * Johan Vromans <jvromans@squirrel.nl> [2005-06-17 17:20]:
>> I can make this information available, if users would be
>> interested.
>
> Access to structured data is always nicer than implementing and
> re-implemeting a parser for its serialized form.

Would it be okay to have a generic 'deal with option' method that
(upon config request; sorry Eric, yet another feature...) gets called
for every option with a hash of relevant information? E.g., name of
the option, type, real name (when called via an alias), the desired
value, and a reference to where to store the value.
What other information would you like to have access to?

-- Johan
0
jvromans
6/18/2005 10:55:21 AM
"A. Pagaltzis" <pagaltzis@gmx.de> writes:

> Since we=A2re at this: the one thing I still fall back to
> Getopt::Std for is small scripts. I love Getopt::Long, but it
> incurs a pretty high startup cost. Is there any chance you can
> play some deferred compilation cards to make it go faster?

This is one of the main reasons that Getopt::Long version 3
development stalled -- the startup overhead would double from
version 2. But in the mean time computers have become 5 to 10 times as
powerful, so would it still be a real problem?

-- Johan

0
jvromans
6/18/2005 10:58:27 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/18/2005 11:04:32 AM
imacat <imacat@mail.imacat.idv.tw> 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

0
jvromans
6/18/2005 11:09:06 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/18/2005 11:18:44 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/18/2005 11:24:34 AM
"Orton, Yves" <yves.orton@de.mci.com> 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
0
jvromans
6/18/2005 11:31:37 AM
Eric Wilhelm <ewilhelm@sbcglobal.net> writes:

> Maybe we'll even manage to hammer it into a standard.

That would really be nice!

-- Johan
0
jvromans
6/18/2005 11:33:00 AM
Eric Wilhelm wrote:
> # The following was supposedly scribed by
> # A. Pagaltzis
> # on Friday 17 June 2005 03:05 am:
>=20
>=20
>>I therefore further posit that the switch you called
>>=E2=80=9C--no-verbose=E2=80=9D is a misnomer.
>>
>>It should be called =E2=80=9C--start-verbose=3D0=E2=80=9D, which indeed=
 should be
>>parsed in precedence order rather than command line order.
>=20
>=20
> Ok.  Then we agree :-)  (can you tell?)
>=20
> Uh.  so everybody is emotional about '--no-'.  Good.  I'll leave that=20
> behaving the way it has.

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

David

0
david
6/18/2005 12:29:02 PM
--===[PGP/MIME_RFC2015]===42B424F4.406C===
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit

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"           => \@opt_fishes,
  "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 ^_*' <imacat@mail.imacat.idv.tw>
PGP Key: http://www.imacat.idv.tw/me/pgpkey.txt

<<Woman's Voice>> News: http://www.wov.idv.tw/
Tavern IMACAT's: http://www.imacat.idv.tw/
TLUG List Manager: http://www.linux.org.tw/mailman/listinfo/tlug

--===[PGP/MIME_RFC2015]===42B424F4.406C===
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (MingW32)

iEYEABECAAYFAkK0JPQACgkQi9gubzC5S1y4BQCgorrTyYIAX8Tvd1hl7sG+BVok
npcAn0qaB6Sj1qRkgavsEiRgh3SPn5KF
=W9RV
-----END PGP SIGNATURE-----
--===[PGP/MIME_RFC2015]===42B424F4.406C===--

0
imacat
6/18/2005 1:43:28 PM
* Johan Vromans <jvromans@squirrel.nl> [2005-06-18 13:05]:
> But in the mean time computers have become 5 to 10 times as
> powerful, so would it still be a real problem?

Yes!

The most problematic scripts I have is a set that’s launched by
GUI events, sometimes in rapid succession. Every microsecond
counts – even on a 2GHz Athlon with plenty of spare memory and
very fast disks. I did my own share of sticking things in
“eval ""” to avoid as much cost as possible, but in the end I had
to throw out Getopt::Long in favour of ::Std to get acceptable
consistent startup times. On slower machines they’re still laggy.
I’ve pondered copypasting the switch processing code…

Optimizing for minimal one-shot cost isn’t fun, it’s painful…

Even with less critical scripts, like my overhaul of the rename
script (where there’s no way I’m dropping to a less capable
switch parser), the fixed overhead is noticable when the script’s
task is not computation intensive.

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
0
pagaltzis
6/18/2005 1:45:01 PM
# 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
---------------------------------------------
0
ewilhelm
6/18/2005 5:03:25 PM
# The following was supposedly scribed by
# Johan Vromans
# on Saturday 18 June 2005 03:55 am:

>Would it be okay to have a generic 'deal with option' method...

>E.g., name of
>the option, type, real name (when called via an alias), the desired
>value, and a reference to where to store the value.

Most of this comes out of Getopt::Crazy::parse_spec().  It does still 
need some work.  But I wonder if this sort of thing (a method that the 
author can call for each option) might be a better approach than a hook 
(if I'm understanding what you propose correctly.) 

--Eric
-- 
"I've often gotten the feeling that the only people who have learned
from computer assisted instruction are the authors."
--Ben Schneiderman
---------------------------------------------
    http://scratchcomputing.com
---------------------------------------------
0
ewilhelm
6/18/2005 5:10:57 PM
Eric Wilhelm <ewilhelm@sbcglobal.net> 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
0
jvromans
6/18/2005 9:14:58 PM
"A. Pagaltzis" <pagaltzis@gmx.de> writes:

> The most problematic scripts I have is a set that=A2s launched by
> GUI events, sometimes in rapid succession.

For purposes like this, I'd write dedicated scripts (e.g., no option
parsing at all), or something simple like a first argument that can be
checked quickly.

> Even with less critical scripts, like my overhaul of the rename
> script (where there=A2s no way I=A2m dropping to a less capable
> switch parser), the fixed overhead is noticable when the script=A2s
> task is not computation intensive.

The only option I see is to split Getopt::Long into a couple of
smaller sub-modules, each optimized for a specific type of
configuration (with / without bundling, variable references / options
hash, and so on).

-- Johan
0
jvromans
6/18/2005 9:26:12 PM
* Johan Vromans <jvromans@squirrel.nl> [2005-06-18 23:35]:
> The only option I see is to split Getopt::Long into a couple of
> smaller sub-modules, each optimized for a specific type of
> configuration (with / without bundling, variable references /
> options hash, and so on).

I don’t think it requires sub-modules (and extra files cause
extra slowdown, too), just judicious use of “eval STRING” to
defer compilation of as much code as possible until it’s actually
needed.

If I were to look at the code to make specific suggestions (or
even write a patch, I dunno), would they be obsolete again soon
with the new design, or is the effort worth it?

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
0
pagaltzis
6/18/2005 10:45:56 PM
* Johan Vromans <jvromans@squirrel.nl> [2005-06-18 23:20]:
> Eric Wilhelm <ewilhelm@sbcglobal.net> 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”
0
pagaltzis
6/18/2005 11:12:54 PM
# The following was supposedly scribed by
# A. Pagaltzis
# on Saturday 18 June 2005 04:12 pm:

>OTOH, with a switch like =E2=80=9C--no-default-fish=E2=80=9D the semantics=
 should
>be obvious from the description itself.
>
>In this respect the =E2=80=9Cun=E2=80=9D prefix is really horribly chosen.

With the 'un', being short for undef() (or "undefine"), I thought it was=20
pretty appropriate.  "--no-default" is a lot to type.  Maybe if one is=20
an alias to the other?

=2D-Eric
=2D-=20
"Everything goes wrong all at once."
=2D-Quantized Revision of Murphy's Law
=2D--------------------------------------------
    http://scratchcomputing.com
=2D--------------------------------------------
0
ewilhelm
6/19/2005 12:14:59 AM
"A. Pagaltzis" <pagaltzis@gmx.de> writes:

>> Something like ++ instead of --.
>
> I think that=A2s ugly. I=A2d 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=3D$HOME/mydb
   mycmd load db=3D$HOME/mydb data1=20
   mycmd load --trace db=3D$HOME/mydb data1=20
   mycmd --trace load db=3D$HOME/mydb data1=20

Note that the 3rd and 4th commands behave significantly different.

Now, I could have forced this in the "-"-style command line look:

   mycmd --command=3Dinit --db=3D$HOME/mydb
   mycmd --command=3Dload --db=3D$HOME/mydb data1=20
   mycmd --command=3Dload --trace --db=3D$HOME/mydb data1=20
   mycmd --trace --command=3Dload --db=3D$HOME/mydb data1=20

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
0
jvromans
6/19/2005 9:08:58 AM
"A. Pagaltzis" <pagaltzis@gmx.de> writes:

> I don=D5t think it requires sub-modules (and extra files cause
> extra slowdown, too), just judicious use of =D2eval STRING=D3 to
> defer compilation of as much code as possible until it=D5s actually
> needed.

Are you sure that deferred compilation will actually help? If you have
a small module that sometimes pulls in a big one (like Carp /
Carp::Heavy) it would make a significant difference. But deferring
compilation of, say, 25% of the code?

Besides, I try to avoid using "eval STRING" at almost any cost. It
introduces the risk of having code that suddenly starts failing under
specific circumstances.

> If I were to look at the code to make specific suggestions (or
> even write a patch, I dunno), would they be obsolete again soon
> with the new design, or is the effort worth it?

If you can produce a proof of concept, I'd glady incorporate it.

-- Johan
0
jvromans
6/19/2005 9:18:19 AM
* Johan Vromans <jvromans@squirrel.nl> [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;
0
pagaltzis
6/19/2005 12:59:58 PM
* Johan Vromans <jvromans@squirrel.nl> [2005-06-19 11:25]:
> But deferring compilation of, say, 25% of the code?

I don’t know how much there is to be saved.

The other option I can think of is kind of wild: do the
option specification parsing/processing that has to be done on
every invocation, regardless of the user input, just once, and
then cache the results somewhere – possibly as Perl code in the
__DATA__ of the caller or some such, much like SelfLoader works.

> Besides, I try to avoid using "eval STRING" at almost any cost.
> It introduces the risk of having code that suddenly starts
> failing under specific circumstances.

Well, I avoid “eval STRING” in regular code as well (motto: “it’s
generally a red flag”), always preferring other means if they are
available. But I’ve never had any problems with it when I used it
with constant strings solely to defer compilation.

Do you have any specific examples of what you are referring to?

Regards,
-- 
#Aristotle
*AUTOLOAD=*_=sub{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
&Just->another->Perl->hacker;
0
pagaltzis
6/19/2005 1:08:51 PM
"A. Pagaltzis" <pagaltzis@gmx.de> writes:

> The other option I can think of is kind of wild: do the
> option specification parsing/processing that has to be done on
> every invocation, regardless of the user input, just once, and
> then cache the results somewhere =E2=80=93 possibly as Perl code in the
> __DATA__ of the caller or some such, much like SelfLoader works.

Yes, this thought has crossed my mind more than once, although I'd go
for an CLI-parser generator that generates an optimized parser sub.

> [...] But I=E2=80=99ve never had any problems with it when I used it
> with constant strings solely to defer compilation.

If the string is constant, and can be tested, yes.
I subroutines are generated dynamically using string eval, the risk I
mentioned is much greater.

-- Johan
0
jvromans
6/19/2005 5:59:57 PM
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.
0
sam
6/19/2005 10:41:15 PM
Reply:

Similar Artilces:

RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
------_=_NextPart_001_01C5757F.9DD140B0 Content-Type: text/plain > -) Structured access to the option settings > -) Option to pass in something other @ARGV to the > arg-processing code. Id be curious what you mean by the first, and Im confused why the obvious solution to the second is not good enough. local @ARGV=@ARGV; Goes a long way you know. Yves ------_=_NextPart_001_01C5757F.9DD140B0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <...

[RFC] Module::CoreList removed modules functionality
--pWyiEgJYm5f9v55/ Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable It has come up on a few IRC channels regarding Module::CoreList and corelist and the fact that whilst one can see when a module first entered core and all the perl versions a module is included with, there isn't a mechanism to indicate when a module departed from core. ( Well, there obviously is if you want to play with %version yourself ). I've come up with two new functions to compliment first_release()=20 and first_release_by_date(): ...

Module in Module
Hi, Is there a way to place a module inside another module (e.g. A feedback module inside a Text/HTML module) ? Cheers Tassos There is a way to inject controls into a module dynamically based on some criteria like a querystring parameter - is that what you are wanting to do?Dylan Barberread my stupid blog http://codemypantsoff.com There's a commercial module "wrapper" on Snowcovered that is designed to hold other modules.  So it is possible.I don't know if you could put a module holding a module inside a module containing a module, but I wouldn't try.  The entire space-time...

modules, modules
This site appears to be the most comprehensive list of free custom modules: www.dnnfaq.com Any other sites? I do like how Rainbow gives you a bucket of them - saves a lot of time over having to snoop around and find some of the DNN ones. Is there also a way to list modules as "certified"? Also - is there a decent repository of skins? I have recently installed version 2.0. Sure wish there were more modules ready for it! That would make it much easier to evaluate the program and give recommendations to my boss. The reason there aren't more 2.0 modules yet is becasue it h...

Getopt module
Hi, Here's some (unfinished) code I am trying to use with Getopt::Std, #!/usr/local/bin/perl -w # use Getopt::Std; use diagnostics; getopts('hn:'); &usage if (defined $opt_h); sub usage { print <<"EOM" USAGE: $0 [-h] -n user\@dom.ain -h This message -n <user\@some.dom.ain> EOM When it's executed, as "test.pl -h" here is what I get in response: Name "main::opt_h" used only once: possible typo at test.pl line 16 (#1) (W once) Typographical errors often show up as unique variable nam...

MX module authors
The next Moose will start warning on various deprecated features, most of which have been deprecated for quite some time without warning. You can take a look at the current list of failures & warnings by checking out http://urth.org/~autarch/mydeps-error.log You should be able to simply search for your PAUSE id to see the status of your modules. It would be great if you could get a warnings-clean release out before the next Moose release, which I'm hoping to do some time in the next week or so. -dave /*=========================================================...

PAR and Getopt::Euclid (access to other modules from one of the modules in PAR archive)
Hello, in a project we are using Getopt::Euclid for commandline processing. Getopt::Euclid reads the definition for the commandline parameters from POD in scripts and Modules. For this, Getopt::Euclid reads the module and parses the POD. This fails with PAR, because the modules are not found: my @caller = caller; if ($caller[1] =~ m/[.]pm \z/xms) { # Save module's POD... open my $fh, '<', $caller[1] or croak ... ... (How)is it possible to access the content of a Module? As I remember, some time ago, PAR unpacked the mod...

Attempt to contact module author Shlomo Yona (SuffixTree module on CPAN)
The module author Shlomo Yona for the Perl Module SuffixTree lists an email address that is no longer valid. An email has been sent to this author's @cpan.org email address as well (I'm hopeful that there will be a response, but as of now haven't). There are bug reports in the RT that include patches ranging from 2 years old to 8 years old. The module was first uploaded in January of 2003, with two subsequent revisions also in January 2003. No activity since then. This message is an attempt to contact Shlomo Yona. If you know how to reach him please let me know. If ...

[RFC] Modules for workers
Hi everyone, As part of the ongoing effort to make (Chrome) Workers useful for platform refactorings, we have been working on a lightweight module loader for workers (bug 872421). This loader implements a minimal version of CommonJS modules, aka require.js. Example: // Setup the loader. We need this once per worker. importScripts("resource://gre/modules/workers/loader.js"); // Import a few modules let Logger = require("resource://gre/modules/workers/logger.js"); let Storage = require("resource://gre/modules/workers/storage.js"); // ... /...

A plea to RFC authors
When writing RFCs that talk about the inclusion of "interesting" new features--things like coroutines, matrix math, bizarre regex theory (yes, I know that's redundant), curried (or garlic'd, or peppered) subs, for example--it would be helpful if there was a good reference in the references section of the RFC. It doesn't have to be on-line, books or periodicals are just fine, nor does it have to be included in the initial proposal, but it should be in the final one, and the earlier the better. A quick rule of thumb should be "If it's not convered in...

[RFC] Module::Husbandry
Part of QA is defining best practices. I've been encoding a few operations I use a lot when writing new perl module distributions in to script form to make my code and POD more consistent. Here's a prerelease of them: http://users.telerama.com/~rbs/src/Module-Husbandry-0.0001.tar.gz and the README is below. Feedback? Thanks, Barrie README for Module::Husbandry ALPHA CODE ALERT: This code is alpha; the API and behaviors are likely to change. This release is for evaluation and feedback; see the TODO file for some ideas of where this might go...

[RFC] protocol Module
I've worked up a fairly simple module called `protocol' that implements some of the features of the Objective-C idea (and I'm sure it's in some other OO languages as well). It still has some bugs (such as error reporting), but seems to work in the initial version. Comments? Questions? Is this a good name for the module? Should it be released on CPAN? If feedback is positive, I'll get it cleaned up and released. You can get the module here: http://moya.tamu.edu/~jgsmith/protocol-0.00_01.tar.gz It uses Module::Build for installation and Filter::Simple ...

RFC: Getopt::SysVInit
Hello, I have written a module for my personal use and was wondering if it might be of use for others. The module is currently called Getopt::SysVInit (Is that a poor choice of name? Suggestions appreciated). It provides a mechanism for reading a single key word option from the command line just as the scripts found in the init.d directory do on most UNIX. My need for this module arose from the need of a control program for daemons I've written. The apachectl program actually gave me the idea for the module. Here is how the module works: use Getopt::SysVInit; $goa =...

[RFC] Astro:: modules
Well, I think I'm done with the bulk of astronomical calculations. I can get the solar longitudes, new moons, etc. I.e., I got the minimum to implement a chinese calendar. Now I'm ready to think about interfaces! Normally I would actually go and come up with interfaces myself, as it's part of development that I enjoy the most, but this particular topic is something that I'm completely ignorant about... I did read up on the material enough for me to implement the calculations, but I really need your help for this. I uploaded the mess that I have so far here: http...

Web resources about - RFC: Getopt::Modern - perl.module-authors

Resources last updated: 11/27/2015 5:42:21 AM