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

[Jonas Karlsson]

On Tue, 21 Nov 2006 00:09:18 +0100, Hisham Muhammad <hisham.hm at gmail.com>  
wrote:

> On 11/20/06, Jonas Karlsson <jonka750 at student.liu.se> wrote:
>> On Mon, 20 Nov 2006 14:49:26 +0100, Hisham Muhammad
>> > $1 works but $2 doesn't, that's the important point.
>> >
>> What do you mean by $2 doesn't? If $1 works, why not $2? Have I missed
>> something?
>
> With Compile foo --flag 2.0, $2 is not 2.0 as the script expects.
>
No, but calling Compile (or any script) with options out of order is not  
supported until _all_ scripts are ported to use "Arg n". In the meantime  
diffent scripts can use the "$n" or "Arg n" syntax, as both will work with  
the current implementation of OptionParser.

>>>>> * 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 actually run CVS on my production box, and I believe others do too.
>>> It's a good way to keep things stable and in check.
>>>
>> Oh, I wasn't aware of that people use the CVS like that. If that's so,
>> maybe releases should be made more often, to ensure that bugfixes are
>> straightened out for the "stable" releases, instead of having to rely on
>> CVS to have things sane?
>
> You're right, we should make more frequent releases. I think I
> expressed myself badly: I run CVS "to keep things stable" not because
> it is more stable than the last release, but to keep in check that no
> bugs were added since the release for when we prepare the next one.

But then you don't have to "cvs up" every day, just a couple of days  
before releases, and then things should be stable. Especially if you  
announce that a release is due and big changes should hold (as you did  
before this release).

> There's no problem in keeping support for the new option parser
> halfway implemented in CVS though (I wouldn't expect changes to all
> scripts to be comitted at once), but it's nice to let CVS users know
> beforehand when things may break and not be taken by surprise. (Maybe
> I was too cautious with this one as it doesn't break anything if
> people keep using options the old way -- it should be fully converted
> before the next release, though).
>
The good thing with CVS is that one can easily revert if things break and  
wait to update the copy until the breaking bugs are fixed (although, not  
without making a but report first :) )

>>> I know it's not ambiguous, but it "looks ambiguous". I'm not keen on
>>> adding features that "should not be used".
I forgot to clarify the part you quoted me on "should not be used" (as  
it's kind of a misquote, when you dropp the part after the quoted part). I  
was only refering to the fact that only long options should be used from  
within scripts and therefore no constructs with short options (including  
stacking) ""should not be used" by script maintainers".

-- 
/Jonas

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