[cli] Why is the Constructor to CommandLine package protected?

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

[cli] Why is the Constructor to CommandLine package protected?

Jason Powers
Hi,
I'm working with version 1.2 (I've checked the 1.3 source as well) and I'm
in need of writing a parser that's a little more strict than the provided
parsers. I really like the rest of the framework, but if I can't instantiate
a CommandLine object without being in the same package I can't extend it
very well.

Is there a reason that this is protected that I'm just not seeing?

Thanks
Jason
Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

Steve Siebert
Hi Jason, 

You're right, the CommandLine constructor is package-private (default) access and therefore can't be extended outside the package.  I don't think this was the intent of the developers, since the CommandLine and CommandLineParser classes are not marked final.  

I attached a quick patch, if the comitters wish to implement.  You'll need to realize the CommandLineParser interface in another class to return your custom CommandLine type, of course, and you should keep the constructor protected/private =).

Cheers,

Steve


On Tue, Sep 28, 2010 at 8:16 PM, Jason Powers <[hidden email]> wrote:
Hi,
I'm working with version 1.2 (I've checked the 1.3 source as well) and I'm
in need of writing a parser that's a little more strict than the provided
parsers. I really like the rest of the framework, but if I can't instantiate
a CommandLine object without being in the same package I can't extend it
very well.

Is there a reason that this is protected that I'm just not seeing?

Thanks
Jason



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

Emmanuel Bourg-3
In reply to this post by Jason Powers
Le 29/09/2010 02:16, Jason Powers a écrit :

> Is there a reason that this is protected that I'm just not seeing?

I suppose it was made private to make clear that instances of
CommandLine are obtained through a parser and not created directly. It
hinders the development of alternative parsers though.

I'll change the accessibility of the constructor and the
addArg/addOption methods to protected so you can easily extend the class.

What kind of strict behavior did you expect from the parsers? CLI 1.3
will introduce a new unified parser, maybe it could be enhanced to
support your use case.

Emmanuel Bourg


smime.p7s (4K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

Jason Powers
What I basically need is a parser that behaves like ls and java (without the
-D part) for long options.

For example, if I have a short option of 'a' and a long option of 'add'. I'd
accept '-a' and '--add', but I would reject '-add'. The new DefaultParser
looks like it does a very good job of trying to figure out what the user
meant and doing it, but I need something that's a little less forgiving.

If you guys like I can code up what I'm thinking and send a patch along
against 1.3.

Thanks
Jason

On Wed, Sep 29, 2010 at 2:09 AM, Emmanuel Bourg <[hidden email]> wrote:

> Le 29/09/2010 02:16, Jason Powers a écrit :
>
>
>  Is there a reason that this is protected that I'm just not seeing?
>>
>
> I suppose it was made private to make clear that instances of CommandLine
> are obtained through a parser and not created directly. It hinders the
> development of alternative parsers though.
>
> I'll change the accessibility of the constructor and the addArg/addOption
> methods to protected so you can easily extend the class.
>
> What kind of strict behavior did you expect from the parsers? CLI 1.3 will
> introduce a new unified parser, maybe it could be enhanced to support your
> use case.
>
> Emmanuel Bourg
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

norm-2
Jason Powers <[hidden email]> writes:

>--001636498aa30587d70491682379
>Content-Type: text/plain; charset=ISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
>What I basically need is a parser that behaves like ls and java (without th=
>e
>-D part) for long options.
>
>For example, if I have a short option of 'a' and a long option of 'add'. I'=
>d
>accept '-a' and '--add', but I would reject '-add'. The new DefaultParser
>looks like it does a very good job of trying to figure out what the user
>meant and doing it, but I need something that's a little less forgiving.
>
>If you guys like I can code up what I'm thinking and send a patch along
>against 1.3.
>
>Thanks
>Jason

A related feature I would like is support for abbreviations, of -- options.
Submitting an ambiguous  abbreviation would generate a parser error. Many,
of the GNU utilities, including ls, have this feature.


>On Wed, Sep 29, 2010 at 2:09 AM, Emmanuel Bourg <[hidden email]> wrote:
>
>> Le 29/09/2010 02:16, Jason Powers a =E9crit :
>>
>>
>>  Is there a reason that this is protected that I'm just not seeing?
>>>
>>
>> I suppose it was made private to make clear that instances of CommandLine
>> are obtained through a parser and not created directly. It hinders the
>> development of alternative parsers though.
>>
>> I'll change the accessibility of the constructor and the addArg/addOption
>> methods to protected so you can easily extend the class.
>>
>> What kind of strict behavior did you expect from the parsers? CLI 1.3 wil=
>l
>> introduce a new unified parser, maybe it could be enhanced to support you=
>r
>> use case.
>>
>> Emmanuel Bourg
>>
>>
>
>--001636498aa30587d70491682379--

    Norman Shapiro
    798 Barron Avenue
    Palo Alto CA 94306-3109
    (650) 565-8215
    [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

Jason Powers
That last ones doesn't seem too bad, though I don't think that the option
class supports a substring match right? It would be doable with the current
options setup though it might look a little clunky.

Is there anything else that 'defines' a GNU style command line that should
be included? My requirements are basically 'make it behave like all of the
other utilities' which are a mix of shell scripts , java, and mysql.

I'm not really sure this should be mixed in with the goal of the default
parser. I really like the way that is looking and working to 'just try and
figure out what the user was getting at'.

On Wed, Sep 29, 2010 at 9:28 AM, <[hidden email]> wrote:

> Jason Powers <[hidden email]> writes:
> >--001636498aa30587d70491682379
> >Content-Type: text/plain; charset=ISO-8859-1
> >Content-Transfer-Encoding: quoted-printable
> >
> >What I basically need is a parser that behaves like ls and java (without
> th=
> >e
> >-D part) for long options.
> >
> >For example, if I have a short option of 'a' and a long option of 'add'.
> I'=
> >d
> >accept '-a' and '--add', but I would reject '-add'. The new DefaultParser
> >looks like it does a very good job of trying to figure out what the user
> >meant and doing it, but I need something that's a little less forgiving.
> >
> >If you guys like I can code up what I'm thinking and send a patch along
> >against 1.3.
> >
> >Thanks
> >Jason
>
> A related feature I would like is support for abbreviations, of -- options.
> Submitting an ambiguous  abbreviation would generate a parser error. Many,
> of the GNU utilities, including ls, have this feature.
>
>
> >On Wed, Sep 29, 2010 at 2:09 AM, Emmanuel Bourg <[hidden email]>
> wrote:
> >
> >> Le 29/09/2010 02:16, Jason Powers a =E9crit :
> >>
> >>
> >>  Is there a reason that this is protected that I'm just not seeing?
> >>>
> >>
> >> I suppose it was made private to make clear that instances of
> CommandLine
> >> are obtained through a parser and not created directly. It hinders the
> >> development of alternative parsers though.
> >>
> >> I'll change the accessibility of the constructor and the
> addArg/addOption
> >> methods to protected so you can easily extend the class.
> >>
> >> What kind of strict behavior did you expect from the parsers? CLI 1.3
> wil=
> >l
> >> introduce a new unified parser, maybe it could be enhanced to support
> you=
> >r
> >> use case.
> >>
> >> Emmanuel Bourg
> >>
> >>
> >
> >--001636498aa30587d70491682379--
>
>    Norman Shapiro
>    798 Barron Avenue
>    Palo Alto CA 94306-3109
>    (650) 565-8215
>    [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

Christopher Schultz-2
In reply to this post by Jason Powers
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jason,

On 9/28/2010 8:16 PM, Jason Powers wrote:
> I'm working with version 1.2 (I've checked the 1.3 source as well) and I'm
> in need of writing a parser that's a little more strict than the provided
> parsers. I really like the rest of the framework, but if I can't instantiate
> a CommandLine object without being in the same package I can't extend it
> very well.

Quick fix: extend CommandLine and add your own constructor that calls
the superclass's constructor.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkyjrA0ACgkQ9CaO5/Lv0PB7QgCfYhkQgIBMOqFVBp/I4/4wT8cf
RJMAnimzGZxLrQtr1IV9k02DycVxoQH7
=TNC0
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

norm-2
In reply to this post by Jason Powers
Jason Powers <[hidden email]> writes:
>--001485f7d4a865024c04916c113e
>Content-Type: text/plain; charset=ISO-8859-1
>
>That last ones doesn't seem too bad, though I don't think that the option
>class supports a substring match right? It would be doable with the current
>options setup though it might look a little clunky.
>
>Is there anything else that 'defines' a GNU style command line that should
>be included?

Some GNU utilities -- for example gcc, treat '-' as '--' is  treated by most
other utilities and have some options that begin with '+' instead of '-'.


    Norman Shapiro

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

Emmanuel Bourg-3
In reply to this post by norm-2
Le 29/09/2010 18:28, [hidden email] a écrit :

> A related feature I would like is support for abbreviations, of -- options.
> Submitting an ambiguous  abbreviation would generate a parser error. Many,
> of the GNU utilities, including ls, have this feature.

Commons CLI supports this too. If ambiguous options are specified on the
command line an exception is thrown.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [cli] Why is the Constructor to CommandLine package protected?

Emmanuel Bourg-3
In reply to this post by Jason Powers
Le 29/09/2010 18:05, Jason Powers a écrit :

> What I basically need is a parser that behaves like ls and java (without the
> -D part) for long options.
>
> For example, if I have a short option of 'a' and a long option of 'add'. I'd
> accept '-a' and '--add', but I would reject '-add'. The new DefaultParser
> looks like it does a very good job of trying to figure out what the user
> meant and doing it, but I need something that's a little less forgiving.
>
> If you guys like I can code up what I'm thinking and send a patch along
> against 1.3.

Sure! Contributions are welcome.

Something I have in mind for the default parser in the next release is a
set of options altering the behavior of the parser. For example an
option disabling the partial matching, another option disabling long
opts used with a single dash (that's your "-add" example), or an option
disabling the Posix style (i.e tar -zxvf).

I wasn't sure this was really needed, your case proves it is.

Emmanuel Bourg

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]