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
A. Pagaltzis [EMAIL PROTECTED] writes:
* 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.
Would it be
A. Pagaltzis [EMAIL PROTECTED] writes:
Since were at this: the one thing I still fall back to
Getopt::Std for is small scripts. I love Getopt::Long, but it
incurs a pretty high startup cost. Is there any chance you can
play some deferred compilation cards to make it go faster?
This is one of
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
On Jun 17, 2005, at 7:49 PM, Rob Janes wrote:
so basically the executive summary is that cpanplus does not report
adequately system dependency failures, like a missing c compiler or a
missing library.
As outlined in my other email, that is because it can not (it has no
way of knowing that
* Johan Vromans [EMAIL PROTECTED] [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 thats launched by
GUI events, sometimes in rapid succession. Every microsecond
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
# 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.
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
On Sat, 18 Jun 2005, Ken Williams wrote:
On Jun 18, 2005, at 6:58 AM, imacat wrote:
But, what if we make clues there? Please correct me if I'm wrong,
but from my experience working with GNU autoconf and automake,
something
like:
test.c:
int
main()
{
}
On Sat, Jun 18, 2005 at 12:06:49PM +0200, Jos I. Boumans wrote:
If they can be published by Module::Build in an unambiguous way, that
might be an option. Parsing the output of an error is not, as far as i'm
concerned -- it would be the responsibility of the installer to tell us
why it was
A. Pagaltzis [EMAIL PROTECTED] writes:
The most problematic scripts I have is a set thats 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
* Johan Vromans [EMAIL PROTECTED] [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 dont think it requires
* 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
# The following was supposedly scribed by
# A. Pagaltzis
# on Saturday 18 June 2005 04:12 pm:
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.
With the 'un', being short for undef()
22 matches
Mail list logo
