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.c...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
