As I've said before, if GetOptions() could be a few-lines wrapper
around the $opt = Getopt::Long-new()... $opt-get([EMAIL PROTECTED]) dance,
this allows the author (of what will most likely be a module if they
want to parse something besides ARGV) to design their own entry
point if need be.
# The following was supposedly scribed by
# Johan Vromans
# on Saturday 09 July 2005 02:58 am:
this allows the author (of what will most likely be a module if they
want to parse something besides ARGV) to design their own entry
point if need be.
I'm puzzled. Basically, you suggest that it is
[EMAIL PROTECTED] (Johan Vromans) writes:
[Quoting Sam Vilain, on June 27 2005, 22:56, in Re: Getopt::Long wis]
If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.
Interfere? No, but elegant?
Currently,
On Jul 5, 2005, at 4:44 AM, Johan Vromans wrote:
... I now strongly lean towards _not_ creating an additional
entry point for this functionality. While GetOptionsFromArray seems
nice, there's also a reason for GetOptionsToHash,
GetOptionsWithNonStandardIntroducer and so on. This would make
[Quoting Sam Vilain, on June 27 2005, 11:35, in Re: Getopt::Long wis]
Johan Vromans wrote:
You mean, you are going to pass things like STDOUT, STDERR, ENV and so
on, to every function that may use them? [1]
Global things are intended to be global, I'd say.
This is why code using CGI.pm
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
[EMAIL PROTECTED] wrote on Monday, June 27, 2005 9:46 AM
Anyway, the next version of Getopt::Long will have the ability to use
an arbitrary array instead of ARGV.
Now, do you want this to be yet another if the first argument
[Quoting Orton, Yves, on June 27 2005, 10:17, in RE: Getopt::Long wis]
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
GetOptionsFromArray?
-- Johan
Orton, Yves wrote:
Imo it would better to expose a different subroutine name for this.
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Is that ruled out for some reason?
If you consider the signature a part of the subroutine name, then
simply making it take an arrayref as the first
[Quoting Sam Vilain, on June 27 2005, 22:56, in Re: Getopt::Long wis]
If passing an array ref first doesn't interfere with the calling
convention, then imho you don't need to change the function name.
Interfere? No, but elegant?
Currently, GetOptions allows an array ref as the first argument
* Orton, Yves [EMAIL PROTECTED] [2005-06-27 11:25]:
Imo it would better to expose a different subroutine name for this.
Ie:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
Sounds like a very good idea to me.
* Johan Vromans [EMAIL PROTECTED] [2005-06-27 11:55]:
# The following was supposedly scribed by
# Johan Vromans
# on Monday 27 June 2005 02:46 am:
sub GetOptions {
GetOptionsArray([EMAIL PROTECTED],@_);
}
GetOptionsFromArray?
That sounds like a great idea.
Any chance of it involving an object (and therefore multi-pass support?)
--Eric
--
Johan Vromans wrote:
You mean, you are going to pass things like STDOUT, STDERR, ENV and so
on, to every function that may use them? [1]
Global things are intended to be global, I'd say.
This is why code using CGI.pm is so hard to wrap, too. Assumptions that
globals will always be globals.
Title: RE: Getopt::Long wishes (was: RFC: Getopt::Modern)
-) Structured access to the option settings
-) Option to pass in something other @ARGV to the
arg-processing code.
Id be curious what you mean by the first, and Im confused why the obvious solution to the second is not good
Greetings,
On Mon, Jun 20, 2005 at 11:06:49AM +0100, Orton, Yves wrote:
-) Structured access to the option settings
-) Option to pass in something other @ARGV to the
arg-processing code.
Id be curious what you mean by the first,
I mean the ability to query Getopt::Long, either by an
Martyn J. Pearce [EMAIL PROTECTED] writes:
It does, and it works, and it is a stylistic thing perhaps, but although
global variables can be made to work, the modern phenomenon of function
arguments are very popular.
You mean, you are going to pass things like STDOUT, STDERR, ENV and so
on, to
* Orton, Yves [EMAIL PROTECTED] [2005-06-20 12:15]:
Im confused why the obvious solution to the second is not good
enough.
local @[EMAIL PROTECTED];
Goes a long way you know.
I don’t like that at all, myself. It works, sure, but then so
does “local $/”, and guess what’s happening to all
# The following was supposedly scribed by
# A. Pagaltzis
# on Monday 20 June 2005 08:57 am:
I don’t see how being able to *optionally* say something like
GetOptions(
[EMAIL PROTECTED],
# ...
);
would detract from anything at all.
I don't think you really need to be able
Le lundi 20 juin 2005 à 09:09, Eric Wilhelm écrivait:
# The following was supposedly scribed by
# A. Pagaltzis
# on Monday 20 June 2005 08:57 am:
I don???t see how being able to *optionally* say something like
GetOptions(
[EMAIL PROTECTED],
# ...
);
would
A. Pagaltzis [EMAIL PROTECTED] writes:
Something like ++ instead of --.
I think thats ugly. Id suggest simply addding another dash [...]
I find it very interesting to note that although we're talking about
quite different semantics, everyone seems to be wanting to stick to
the ancient syntax
* Johan Vromans [EMAIL PROTECTED] [2005-06-19 11:15]:
I find it very interesting to note that although we're talking
about quite different semantics, everyone seems to be wanting
to stick to the ancient syntax of --style command line
options.
I dont see why it is ancient instead of sensible.
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;
Eric Wilhelm [EMAIL PROTECTED] writes:
Ok. Then my previous argument stands. If the --no- means unset any
hard-coded or config-file defaults, then it shouldn't be evaluated in
command-line order.
Good deduction, but the premise does not hold. --no- does not mean
unset any [...] defaults,
Eric Wilhelm [EMAIL PROTECTED] writes:
Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition of the semantics?
I never suggested that it should be disallowed. Only that it should be
equivalent to '--no-foo --foo'.
That's part of the clearly defined
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
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
Eric Wilhelm [EMAIL PROTECTED] writes:
What I'm trying to do with Getopt::Modern here is to establish some
conventions which allow this to happen internally. This saves the
author some code and gives the user a guaranteed consistent experience
with multiple programs.
The debate on the
Eric Wilhelm [EMAIL PROTECTED] writes:
Because I had originally built that as a wrapper around Getopt::Long, I
had a laundry-list of what didn't work.
This would have been interesting for me to know.
In fact, as I mentioned I would be happy for G::L to have this
functionality, but I doubt
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
# 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
imacat [EMAIL PROTECTED] writes:
[...] But, then, is this whole thread that meaningless?
I don't think so. Many good ideas and suggestions have come by, and
though not all ideas are equally viable, many people spend energy
on communicating ideas -- which is fundamental to open source
software.
Eric Wilhelm [EMAIL PROTECTED] writes:
Maybe we'll even manage to hammer it into a standard.
That would really be nice!
-- Johan
Orton, Yves [EMAIL PROTECTED] writes:
I currently have two projects that address this issue: Getopt::Toolkit
(which is based on Getopt::Long) and Getopt::Long version 3 (which is
a complete redesign, a.k.a. Getopt::Long on steroids). Merging the two
projects into a single new Getopt::Long
* Johan Vromans [EMAIL PROTECTED] [2005-06-18 23:20]:
Eric Wilhelm [EMAIL PROTECTED] writes:
Is '--un-' not distinctive enough?
I believe there's more involved that adding the --un-
semantics. For example, precedence order parsing yields
different results from left to right parsing.
I
Eric Wilhelm [EMAIL PROTECTED] writes:
You wouldn't say
--foo --no-foo
if you just meant
--no-foo
Would you?
I think the basic question is, what do you expect from a certain
combination of options and arguments. For example,
--foo arg1 --no-foo arg2
This can be interpreted as:
Eric Wilhelm [EMAIL PROTECTED] writes:
Do you mean to say that 99% of the time (when --foo and --no-foo are
both present) that it is because somebody has an alias with a --foo
flag written into it?
Independent of percentages, why disallow --foo --no-foo provided
there's a clear definition
Eric Wilhelm [EMAIL PROTECTED] writes:
Ok, and maybe I showing my age here, but is *this* where the
negated-options thing comes from? I.E. is this the historic (and
entire) reason for having the 'foo!' syntax in Getopt::Long?
No, it's because of a) defaults. Sometimes a flag is enabled by
Eric Wilhelm [EMAIL PROTECTED] writes:
Please see this essay
http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt
Nice piece of writing, but it contains several flaws. For example:
If your spouse tells you to get tuna and halibut, but not any
other
On Fri, 17 Jun 2005 10:57:26 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
Eric Wilhelm [EMAIL PROTECTED] writes:
Please see this essay
http://scratchcomputing.com/svn/Getopt-Modern/trunk/data/notes/why_order_matters.txt
If your spouse tells you to get tuna and halibut, but not any
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 01:35]:
I dont understand. If there was no need to be able to say
--foo --no-foo, then why do both exist?
No, no, no. Start over.
1. There is a need.
2. It doesn't matter what order the user gives the options in,
the result should be the
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
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
Title: RE: RFC: Getopt::Modern
[Quoting Eric Wilhelm, on June 16 2005, 15:14, in Re: RFC:
Getopt::Mo]
15 years * n requests/year = 15*n degrees of flexibility =
unpredictable
Hmm. I'd say
15 years * n requests/year * m happy users = reliability
which is as meaningless as your
# 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
* Johan Vromans [EMAIL PROTECTED] [2005-06-17 17:20]:
I can make this information available, if users would be
interested.
Access to structured data is always nicer than implementing and
re-implemeting a parser for its serialized form.
So if it doesnt take too much effort, it would be nice to
# The following was supposedly scribed by
# imacat
# on Friday 17 June 2005 02:51 am:
I did not notice the go_shop problem. But I think it's trivial to
solve that with Getopt::Long:
my @conf_fishes = read_conf(fish); # get qw(trout)
my @opt_fishes = qw();
my $opt_nofish = 0;
On Fri, 17 Jun 2005 08:45:26 -0700
Eric Wilhelm [EMAIL PROTECTED] wrote:
Ok. Then my previous argument stands. If the --no- means unset any
hard-coded or config-file defaults, then it shouldn't be evaluated in
command-line order.
Well, as I said, if you would like unordered options,
# 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
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:00]:
In fact, as I mentioned I would be happy for G::L to have this
functionality, but I doubt that program-order evaluation (one
of the main design goals) is going to fit without some serious
restructuring.
Why do you keep claiming that? Both
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:20]:
In any case. How does G::L evaluate in precedence order?
That's why I'm writing G::?
By parsing into two separate variables, and allowing separate
module-client code evaluate how to react to the values in those
to variables. A working
On Fri, 17 Jun 2005 09:08:51 -0700
Eric Wilhelm [EMAIL PROTECTED] wrote:
Yes. You can solve it. It's not really trivial by the time you add
meats, cheeses, breads, and mustard though. All of these things come
in many flavors and you might have a config file with your favorites
listed in
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-17 18:15]:
It's not really trivial by the time you add meats, cheeses,
breads, and mustard though. All of these things come in many
flavors and you might have a config file with your favorites
listed in it so that running go_shop with no arguments
--- A. Pagaltzis [EMAIL PROTECTED] wrote:
Why do you keep claiming that? Both me and someone else already
posted working code that shows how you can trivially do what you
want with Getopt::Long if you just use two different variables.
Which, to me, is the clincher. Getopt::Long can easily
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:
* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:
I'm still trying to figure out why it's carried on this long.
Calling the new module ::Modern and claiming that ::Long is
crufty, too flexible, and unpredictable probably set the mood.
Amen.
On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote:
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:
* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:
I'm still trying to figure out why it's carried on this long.
Calling the new module ::Modern and claiming that ::Long is
crufty,
# The following was supposedly scribed by
# Ken Williams
# on Friday 17 June 2005 01:07 pm:
Calling the new module ::Modern and claiming that ::Long is
crufty, too flexible, and unpredictable probably set the mood.
Amen. Eric, that was really obnoxious. You might have had more luck
convincing
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]:
Imagine this is Eric's first try at publishing a module.
Then what is http://search.cpan.org/~ewilhelm/? :-)
You could take at least a cursory look before making such
assumptions
Regards,
--
#Aristotle
On Fri, Jun 17, 2005 at 11:22:58PM +0200, A. Pagaltzis wrote:
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 22:45]:
Imagine this is Eric's first try at publishing a module.
Then what is http://search.cpan.org/~ewilhelm/? :-)
You could take at least a cursory look before making such
On Jun 17, 2005, at 3:37 PM, Austin Schutz wrote:
On Fri, Jun 17, 2005 at 03:07:27PM -0500, Ken Williams wrote:
On Jun 17, 2005, at 2:13 PM, A. Pagaltzis wrote:
* Ovid [EMAIL PROTECTED] [2005-06-17 20:15]:
I'm still trying to figure out why it's carried on this long.
Calling the new
On Fri, 17 Jun 2005 14:34:59 -0700
Austin Schutz [EMAIL PROTECTED] wrote:
Was I assuming, or was I imagining? The point is that the
community can be unnecessarily combative and ugly, a point which to
my eyes you have helped illustrate.
Well, I suppose, I am one of those you
* Austin Schutz [EMAIL PROTECTED] [2005-06-17 23:40]:
The point is that the community can be unnecessarily combative
and ugly, a point which to my eyes you have helped illustrate.
Yes, I was rude. At first I was frustrated after trying to find
information about Erics proposal other than this
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
On Thu, 16 Jun 2005 11:21:04 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
* lacks predictable behaviour
I fail to see your point here. Options are handled from left to
right, which makes perfect sense.
I have watched the on-line slide. The slide said:
* lacks predictable
Authors
Subject: Re: RFC: Getopt::Modern
On Thu, 16 Jun 2005 11:21:04 +0200
Johan Vromans [EMAIL PROTECTED] wrote:
* lacks predictable behaviour
I fail to see your point here. Options are handled from left to
right, which makes perfect sense.
I have watched the on-line slide. The slide
: 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
# 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
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
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
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
# The following was supposedly scribed by
# Ken Williams
# on Thursday 16 June 2005 08:42 pm:
In my experience it's more like 99.999%. And I can't actually
remember seeing a legit case of the 0.001% coming out of my fingers,
but I'm throwing it in there as a bone.
The alias thingy is just an
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
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 --
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
* Eric Wilhelm [EMAIL PROTECTED] [2005-06-16 02:05]:
English:
http://scratchcomputing.com/developers/Getopt-Modern/
Your presentation gets about two slides in before it chokes on
404s.
I looked at the code and didnt see much that warranted a new
module and an OO API.
The example you show on
73 matches
Mail list logo
