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*
