Mailing-List: contact users-help@groovy.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@groovy.apache.org
Subject: Re: Example of CliBuilder with "optionalArg: true"?
To: users@groovy.apache.org
References: <56B106A3.70803@gmail.com>
 <B8D164BED956C5439875951895CB4B2250BE80D4@CAFRFD1MSGUSRJH.ITServices.sbc.com>
 <1454951518.2264.64.camel@winder.org.uk>
From: "David M. Karr" <davidmichaelkarr@gmail.com>
Message-ID: <56B917C3.8010905@gmail.com>
Date: Mon, 8 Feb 2016 14:33:39 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <1454951518.2264.64.camel@winder.org.uk>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

On 02/08/2016 09:11 AM, Russel Winder wrote:
> On Tue, 2016-02-02 at 19:56 +0000, KARR, DAVID wrote:
> […]
>> With a  simple script like this:
>> ----------------
>> def cli = new CliBuilder()
>> cli.with {
>>    f(args: 1, optionalArg: true, "set a value")
>> }
>> def options = cli.parse(args)
>> def fval = options.f
>> println "fval[" + fval + "] class[" + fval.getClass().getName() + "]"
>> def fvalue = options.fs
>> println "fvalue[" + fvalue + "]"
>> ---
>>
>> If I run this with "-f abc", I get:
>> --------------
>> fval[abc] class[java.lang.String]
>> fvalue[[abc]]
>> ----------------
>>
>> But if I run it with "-f", I get:
>> ------------
>> fval[true] class[java.lang.Boolean]
>> fvalue[true]
>> -------------
> And if you run without -f on the command line you get:
>
> fval[false] class[java.lang.Boolean]
> fvalue[false]
>
> So I think we are looking at this being a feature of options with the
> optionalArg property set. Without it not having an argument to -f
> fails.
>
>> I suppose I could hack something with this information, but I would
>> think there would be something more explicit to tell me whether an
>> argument was supplied for the option.
> Thinking about this, I would say it is right that this behaviour is a
> feature, and that it is what the code has asked for: an option that can
> deliver presence or a value. When the is a value deliver it, otherwise
> deliver a Boolean stating whether the flag was present.
>
> Clearly managing this type of option is non-trivial, but I think this
> is not a bug.
>
Thanks for doing that analysis.

Whether it's a bug is debatable, but I think it's clear that overloading 
behaviors often create confusion.  A friendlier interface would separate 
the notion of "presence of the option" from "value of the argument".  
However, doing that might make all references to options more verbose, 
which is certainly not ideal.

I suppose an improvement could be made by just putting a little 
pseudocode algorithm in the doc that shows how you would either retrieve 
a value if it's present, or determine it's not there, I suppose by 
checking the class of the value returned from "options.<option>".  The 
only time you have a value is when the class is "java.lang.String".  
Would that be correct?