I didn't start the "_" or "__" convention for commands, I just leverged
it to make the commands hidden.
I admit, it's my Unix history that makes this seem ok. In Unix everything
is text and there's precious little metadata.
You're right, having explicit metadata to control this would be cleaner.
I'll add it to the list for a future refactoring. A lot of the existing
metadata needs to be refactored to be common between commands and options.
Jason Lee wrote on 08/27/10 06:39 AM:
> To be honest, I've never liked the "_" prefix for hiding commands (or
> understood why some have "_" and others have "__"). I understand it's
> easier to implement, but it's also pretty much a magic string, which is
> rarely, I think, good a idea. I'd much rather see a parameter on the
> attribute, but that ship has probably already sailed for the commands,
> and perhaps it's best to be consistent on the parameters. Consistency
> aside, for what it's worth, I vote against the magic string. :)
>
> On 8/27/10 1:49 AM, Bill Shannon wrote:
>> Just like we have hidden commands (name starts with "_"),
>> Bhakti has asked for hidden options to commands. It's easy
>> to change the code that generates the usage message to ignore
>> options that start with "_".
>>
>> Harder would be to add @Param(hidden=true).
>>
>> Does anyone object to doing the same for options as we do for commands?
>>
>> So, if you wanted a hidden "force" option, you would declare it
>> @Param(name="_force") and specify it on the command line as "--_force".
>>
>> Of course, we could use any other special character we want. I just
>> chose "_" for consistency with hiddden commands. We could, for instance,
>> use "-", giving us a CLI option of "---force", which looks a bit nicer
>> but may be too subtle and easily confused.
>>
>> Comments?
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: admin-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: admin-help_at_glassfish.dev.java.net
>>
>
>