Sorry, if I missed the links, I did not see them ;)
Looking at xbean they also have the type info on the converter, e.g.
public static void registerConverter(Converter converter) {
if (converter == null) throw new NullPointerException("editor is null");
Class type = converter.*getType*();
registry.put(type, converter);
So what is now the issue?
Cheers, Anatole
2015-01-20 17:57 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> already shared the link for xbean:
>
> https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/PropertyEditors.java
> and more particularly
>
> https://svn.apache.org/repos/asf/geronimo/xbean/trunk/xbean-reflect/src/main/java/org/apache/xbean/propertyeditor/CollectionUtil.java
> (of course this code is very old but the format shoudnt change). For
> spring it uses commons-lang code (fork surely?):
>
> http://grepcode.com/file/repo1.maven.org/maven2/org.springframework/spring-core/3.0.2.RELEASE/org/springframework/util/StringUtils.java#StringUtils.commaDelimitedListToSet%28java.lang.String%29
>
>
>
> Romain Manni-Bucau
> @rmannibucau
> http://www.tomitribe.com
> http://rmannibucau.wordpress.com
> https://github.com/rmannibucau
>
>
> 2015-01-20 17:50 GMT+01:00 Anatole Tresch <[email protected]>:
> > Hi Romain
> >
> > 2015-01-20 17:39 GMT+01:00 Romain Manni-Bucau <[email protected]>:
> >
> >> to be honest I don't see where is the hard part here:
> >> 1) type registration: we adopt 2 registrations mode as for property
> sources
> >> 1a) direct mode MyImpl -> use reflection (or meta if we want to be
> >> verbose) to get the Type
> >>
> >
> > -> Once more: Reflection will not work. The other things tbd.
> >
> >
> >
> >> 1b) kind of provider where we pass a context which register in the
> >> config (config context ATM) the converter:
> >>
> >> public class MyConverters implements ConvertersProvider {
> >> public void registerConverters(ConverterBootsrapContext ctx) {
> >> ctx.register(new MyTypeLiteral<List<String>>() {}, new
> >> MyConverter(true, 1));
> >> }
> >> }
> >>
> >
> > -> No this apporach is not part of the current API. We can register
> > directly PropertyConverter. There is no such thing like
> > a ConverterProvider. If so we could add the target type to the
> > ConverterProvider I agree. That was one of my proposals.
> >
> >
> >
> > 2) about list, map etc modelling: here we don't have much the choice
> >> we should just do what is common (and if we still think to a spec this
> >> is the way to go instead of thinking we are better than everything
> >> existing). References I commonly use or used are xbean and spring and
> >> both are more or less aligned.
> >>
> >
> > Just a short personal advice: If you want people to have an idea about
> > what to you talk you should either copy some code or at least add some
> > direct links to the APIs you are talking of. If not your efforts will be
> > not reflected. Most of the guys do not have time to search the exact
> > locations of what you are talking about ;(
> >
> > 3) agree about events but this one should be tackled after the first
> >> release IMO
> >>
> >>
> >> Romain Manni-Bucau
> >> @rmannibucau
> >> http://www.tomitribe.com
> >> http://rmannibucau.wordpress.com
> >> https://github.com/rmannibucau
> >>
> >>
> >> 2015-01-20 17:28 GMT+01:00 Anatole Tresch <[email protected]>:
> >> > I think guys we really have more important things to discuss than
> these.
> >> > There are wuestion open about how to deal with type registration for
> >> > ProeprtyConverters, list property modelling and we did not even
> started
> >> > with event handling. I propose you guys put your energy on these tasks
> >> and
> >> > stop restarting the same discussion again and again.
> >> >
> >> > 2015-01-20 17:17 GMT+01:00 Romain Manni-Bucau <[email protected]
> >:
> >> >
> >> >> yep, our build is complicated and we finally dont propose anything
> >> >> valuable thanks to it so why continuing this way?
> >> >>
> >> >>
> >> >> Romain Manni-Bucau
> >> >> @rmannibucau
> >> >> http://www.tomitribe.com
> >> >> http://rmannibucau.wordpress.com
> >> >> https://github.com/rmannibucau
> >> >>
> >> >>
> >> >> 2015-01-20 17:06 GMT+01:00 Werner Keil <[email protected]>:
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> In all cases you break java 8 lambdas, not an issue by itself but
> we
> >> >> >> should maybe think removing this java 8 module which will soon be
> >> only
> >> >> >> justified by Optional which is highly controversed.
> >> >> >>
> >> >> >>
> >> >> > What exactly do you mean by that, do you suggest merging the
> codebase
> >> >> here
> >> >> > because except for Optional there is little value of a Java 8+
> >> >> approach?;-)
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > *Anatole Tresch*
> >> > Java Engineer & Architect, JSR Spec Lead
> >> > Glärnischweg 10
> >> > CH - 8620 Wetzikon
> >> >
> >> > *Switzerland, Europe Zurich, GMT+1*
> >> > *Twitter: @atsticks*
> >> > *Blogs: **http://javaremarkables.blogspot.ch/
> >> > <http://javaremarkables.blogspot.ch/>*
> >> >
> >> > *Google: atsticksMobile +41-76 344 62 79*
> >>
> >
> >
> >
> > --
> > *Anatole Tresch*
> > Java Engineer & Architect, JSR Spec Lead
> > Glärnischweg 10
> > CH - 8620 Wetzikon
> >
> > *Switzerland, Europe Zurich, GMT+1*
> > *Twitter: @atsticks*
> > *Blogs: **http://javaremarkables.blogspot.ch/
> > <http://javaremarkables.blogspot.ch/>*
> >
> > *Google: atsticksMobile +41-76 344 62 79*
>
--
*Anatole Tresch*
Java Engineer & Architect, JSR Spec Lead
Glärnischweg 10
CH - 8620 Wetzikon
*Switzerland, Europe Zurich, GMT+1*
*Twitter: @atsticks*
*Blogs: **http://javaremarkables.blogspot.ch/
<http://javaremarkables.blogspot.ch/>*
*Google: atsticksMobile +41-76 344 62 79*
