commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adrian Crum <adrian.c...@sandglass-software.com>
Subject Re: [SANDBOX][CONVERTER] who's taking care?
Date Wed, 26 Oct 2011 21:25:48 GMT
I am the author of most of the code, and it did not come from BeanUtils 
- it is an original work. Any similarity to BeanUtils is purely 
coincidental.

I am always open to improvements. Your ideas sound fine to me - go ahead 
and provide some patches and I will look them over.

The roadmap is to get the issues with deploying the site fixed so I can 
work on SEO and hopefully generate some interest in the project.

-Adrian

On 10/26/2011 9:42 PM, Simone Tripodi wrote:
> Hi Adrian!
> nice to see you involved here!
>
> So, I took few time to reorganize my ideas and I would like to discuss
> with you how to make a new [convert] component,.
>
> For what I can see, the bigger part of the codebase has been kindly
> borrowed from BeanUtils - which is fine - but, like always, I am
> convinced we can give our users new experiences of using commons APIs.
> Please take in consideration that I didn't gave any try and the
> following below are random thoughts I had while driving to come back
> home, so apologize in advance if something wouldn't sound correct.
>
>   * The first modification I'm proposing is about managing types
> automagically - taking a look at GoogleGuice's TypeLyteral[1] it is
> possible to understand that is possible to do some magic with Java
> Generics, that would allow discovery types at runtime.
> That would mean that converter types can be discovered at runtime -
> without the users have to specify them - and that object type under
> conversion can be discovered as well.
> Guice code is licensed under ASL2.0 so parts could be extracted for our needs.
>
>   * The second proposal concerns about fluent APIs. Taking advantage
> fromm the previous point, the existing pattern
>
>      getConverter( Class<?>, Class<?>  ).convert( Object );
>
> could be replaced by a fluent one:
>
>   <S, T>  T  convert( S ).to( Class<T>  )
>
>   * The third proposal is about the loaders: IMHO the auto-loaders are
> not so elegant and a ServiceLoader pattern would be more canonical -
> and enough.
> Anyway I like the public API to register converters - ServiceProvider
> should not be a constraint - and we could modify them in a more fluent
> way:
>
>     <S, T>  convert( Class<S>  ).to( Class<T>  ).withConverter(
> Converter<? extends S, ? extends T>  )
>
> So, what are your opinions/roadmaps about this component?
> Many thanks in advance, all the best!
> Simo
>
> [1] http://google-guice.googlecode.com/git/javadoc/com/google/inject/TypeLiteral.html
>
> http://people.apache.org/~simonetripodi/
> http://simonetripodi.livejournal.com/
> http://twitter.com/simonetripodi
> http://www.99soft.org/
>
>
>
> On Tue, Oct 25, 2011 at 7:17 PM, Adrian Crum
> <adrian.crum@sandglass-software.com>  wrote:
>> I am taking care of it, but it hasn't been updated in awhile because all of
>> the recent Maven work broke the build/deploy process.
>>
>> -Adrian
>>
>> On 10/25/2011 5:33 PM, Simone Tripodi wrote:
>>> Hi all guys,
>>> I need something similar to Converter and of course I don't want to
>>> reinvent the wheel - I have anyway a couple of ideas to add to the
>>> existing sandbox component.
>>> Who's currently taking care about that sandbox so we can speak about it?
>>> TIA, all the best
>>> Simo
>>>
>>> http://people.apache.org/~simonetripodi/
>>> http://simonetripodi.livejournal.com/
>>> http://twitter.com/simonetripodi
>>> http://www.99soft.org/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message