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
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));
}
}
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.
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*
