Re: [Jewelcli-users] ParameterizedTypeImp support for an @Option

[Eduard W. <edi...@gm...>]

Hi Tim,

First, glad you are still interested and developing the project.

We are using JewelCli in another open source project and I would be
interested in contributing new features to it (such as: generic return type
for @Option, pluggable formatting strategies for help requests, i18n)

I think moving to git (and github) makes indeed collaboration easier.

I've tried an implementation of generic return type for @Option
https://github.com/ediweissmann/jewelcli/commit/12c34bc1fc8b94b0364d92e21f653cf913d3cafb

There are two unfinished things, related to fluent-reflection API (imo),
marked with TODO in ArgumentTyperImpl class

I would appreciate some feedback regarding the changeset above, to
understand if this is going in the right direction.

Thanks,
Edi

On Mon, Oct 17, 2011 at 3:54 PM, Tim Wood <fla...@gm...> wrote:

> Hi,
>
> You are right, at the moment it is only supported for lists. I have
> been working on a new version with a different implementation of the
> reflection code which I hope will help with these issues.
>
> I have quite recently moved the source code for jewelcli onto github
> https://github.com/lexicalscope/jewelcli
>
> Hopefully this will make collaboration easier and the source code more
> accessible for people.
>
> Its a bit messed up at the moment, as I am in the process of moving
> the code to a different package name "com.lexicalscope" (I have had a
> few complaints from some people feeling that the current one being a
> bit inappropriate to show up in stack traces!). I will however leave
> the old package names in for a while and delegate them onto the new
> ones.
>
> The version that is in github also has a few dependencies that I don't
> intended to be there in the next release version.
>
> You are welcome to take a look at it and submit some patches (using
> git or by email), but you may find it unusually difficult at the
> moment as half of the project is using one approach to reflection and
> half another! I expect to have completed the transition and released a
> new version in the next 2 months or so.
>
> Tim
>
>
> On Sun, Oct 9, 2011 at 12:15 AM, Eduard Weissmann
> <edi...@gm...> wrote:
> > Hi,
> > Appologies for the possible duplicate email to the mailing list.
> > I'm trying to use a generalized type as a return type for an option.
> > @Option(...)
> > SomeType<SomeOtherType> getSomeType();
> > This fails with java.lang.ClassCastException:
> > sun.reflect.generics.reflectiveObjects.ParameterizedTypeImpl cannot be
> cast
> > to java.lang.Class
> > at
> >
> uk.co.flamingpenguin.jewel.cli.ArgumentSpecificationImpl.<init>(ArgumentSpecificationImpl.java:25)
> > at
> >
> uk.co.flamingpenguin.jewel.cli.OptionSpecificationImpl.<init>(OptionSpecificationImpl.java:22)
> > at
> >
> uk.co.flamingpenguin.jewel.cli.OptionsSpecificationImpl.<init>(OptionsSpecificationImpl.java:44)
> > at uk.co.flamingpenguin.jewel.cli.CliImpl.<init>(CliImpl.java:24)
> > at
> uk.co.flamingpenguin.jewel.cli.CliFactory.createCli(CliFactory.java:23)
> > Seems generalized types are supported for lists, but not for "non-list"
> > types.
> > Is there any way I could use a generalized type as per the setup I have
> > above?
> > Also, is the project still being maintained/developed, would you be
> > interested in a patch adding support for the above (in case its not there
> > yet)?
> > Thanks,
> > Eduard
> >
>