Fair enough...
2015-01-20 18:22 GMT+01:00 Romain Manni-Bucau <[email protected]>: > if you know the reason just look the history of this project, generics > didnt exist when it was written. That's also why it is using Class > (and not Type). > > > Romain Manni-Bucau > @rmannibucau > http://www.tomitribe.com > http://rmannibucau.wordpress.com > https://github.com/rmannibucau > > > 2015-01-20 18:18 GMT+01:00 Anatole Tresch <[email protected]>: > > 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* > -- *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*
