[gobolinux-devel] [gobolinux-commits] tools/Scripts/Functions OptionParser

[Jonas Karlsson]

On Mon, 20 Nov 2006 02:54:23 +0100, Hisham Muhammad <hisham.hm at gmail.com>  
wrote:

> On 11/19/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>> I've just commited my new implementation of OptionParser. The new
>> functionallity can be found in the short log, but I thought I might give
>> some examples to clear things up. Using Compile as an example, valid  
>> calls
>> are:
>>
>> Compile -bS Foo
>> Compile Foo --no-sign
>> Compile -VnFooBar --version=2.3 Foo
>> Compile -xppc Foo
>> Compile -bGc"--no-app --without-lib" Foo
>>
>> For the arguments there are a new array, $Arg, to be used instead of $1,
>> $2 in combinations with shift. $Arg[0] is the same as $0 and then the
>> arguments are numbered in the order of appearance.
>>
>> Even though there's a new way of accessing arguments this commit didn't
>> break the old one, but people should try to change the way arguments are
>> handled in the existing scripts, using $Arg instead of $1 etc.
>>
>> Questions, views, objections? - Please! :)
>
> Ok, here go my questions, views and objections:
>
> * First of all, if this is in, then _all_ scripts have to be changed
> to use $Arg. As it stands, it is advertising broken functionality, as
> "Compile Foo --batch 2.0" does not work.

Yes, but it could be done later as the old method of $1 still works. I  
didn't want to make too many changes in one commit (and hoped that  
somebody would help me in the rewriting :) )

> * While I did tell you offlist that I thought the new option parser is
> a great addition, I think  you should have posted this on the -devel
> list before comitting, since it's a big change that affects all
> scripts.

Oh, I thought you meant to wait until next release was out.
To be honest I think we are too kind with our CVS. Users that track CVS  
should know that it might break. If this breaks anything it's very easy  
for any user to revert, as it's just to either remove the comment at the  
end of Parse_Options or just change the names so that Parse_Options_Old  
becomes Parse_Options again. Anyhow, I've tested the most used scripts and  
none break to my knowledge. That's why I need larger testing.

> * I have restrictions wrt stacking short arguments and using them with
> entry values. Things like "-xbla" look ambiguous.

I thought of that and as it _should not_ be used by any script maintainer,  
a user could easily use it as it knows what should be there and options  
that require an argument is greedy. For example

Compile -xbla foo
is the same thing as
Compile --cross-compile bla foo

as the -x will use the rest of the string as an argument it will not  
consider enabling --batch (if this is what you mean).

> * Using `Arg 1` instead of ${Arg[1]} looks cleaner (a matter of
> taste), more consistent with the rest of the option parser. I concede
> it's less efficient, but they shouldn't be used a lot anyway: they're
> meant to be assigned to variables with meaningful names instead of
> being referred through numbers.

I know that, as we discussed that, but then I thought that it may be used  
with backquotes in assignement and I don't like the idea of wrapping  
multiple backquotes. But as $Arg isn't implemented in any scripts this  
could easily be changed before anyone changes a script to use the new  
interface.

>
> Hope I didn't sound too harsh. I think revamping the option parser is
> a great work which will be appreciated by all users! (me included)
>
> But you _did_ ask for objections... ;)
>
Not at all too harsh, but I do think you're still to conservative (this  
time wrt CVS stability) ;)

-- 
/Jonas

Using Opera's revolutionary e-mail client: http://www.opera.com/mail/