answered inline 2015-01-20 17:19 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Romain > > 2015-01-20 17:02 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> >> >> performance overhead at runtime = 0...you shouldn't do it at runtime >> but at registration time. > > > -> Base on what information? >
the fact it is not called? if you use this when you register the converter then you dont need it anymore and you build your meta at registration and didnt pollute the API with new annotations. > > >> > Also when we would add a method returning the expected formats (which I >> > think would be a very useful thing) we would loose the functional >> aspects, >> > if we add the >> This is why making the type the contract makes sense here. >> >> -> Dont get the point. > if I have MyPropertyConverter<Foo>. The type says me what I need (ie Foo) so why doing: @TamayaMeta(Foo.class) MyPropertyConverter<Foo> ? You'll surely speak about hierarchy etc? It is of course true but 1) most of the time you can deduce it counting the distance to the desired class 2) if you really want to specify it you can as you mentionned add an annotation but not by default to keep it simple and readable > >> >> > I see the following options currently: >> > 1) Define an annotation, e.g. @ConverterSpec to add to the meta-info >> > automatically for the auto-registered PropertyProvider instances. >> > 2) Add an additional interface, extending PropertyProvider that adds the >> > additional methods. This interface then must be used for registration and >> > adds the missing functionality. >> > 3) We could let be PropertyProvider to be non functional, but add in >> Java 8 >> > an additional method to Configuration, which tykes a Function<String,T>. >> > >> >> 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. >> > > This is simply not true at all: > - 1 Will not break it at all and will be Java 7 compatible. > - 2 Will also not break it, since the extended interface is only used for > regitration not for the Configuration interface, where > you can pass a Lambda starting with Java 8. > - 3 Would not break Lambdas, because in Java 7 PropertyProvider is not > functional because there is no such concept, and in Java 8 you have the > additional method, which takes a Lamba. > > 2 points here 1) if you split that much the API then I say (again) what I said in j7/j8 thread: tamaya will fork by itself and both will not be maintained correctly 2) that said this confirms what is said before: you dont need this getTargetType() > > > >> >> > -Anatole >> > >> > >> > 2015-01-20 16:33 GMT+01:00 Romain Manni-Bucau <[email protected]>: >> > >> >> The annotation by itself doesn't make of the interface a >> >> FunctionalInterface or the opposite (ie you can be without it) - so >> >> yes this is fully useless from a code/bytecode point of view. That's >> >> because getTargetType() was added. >> >> >> >> I'd just remove it and use reflection to determine it. We would then >> >> be able to do a lot more than simple Class which are more and more >> >> java 1.4 (it is very funny to see it aside java 8 code ;)) >> >> >> >> >> >> Romain Manni-Bucau >> >> @rmannibucau >> >> http://www.tomitribe.com >> >> http://rmannibucau.wordpress.com >> >> https://github.com/rmannibucau >> >> >> >> >> >> 2015-01-20 16:18 GMT+01:00 Werner Keil <[email protected]>: >> >> > How, did it lose the annotation or was the method signature changed >> >> > violating the Functional Interface definition? >> >> > >> >> > Werner >> >> > >> >> > On Tue, Jan 20, 2015 at 4:10 PM, Reinhard Sandtner < >> >> > [email protected]> wrote: >> >> > >> >> >> Hey guys >> >> >> >> >> >> build is broken since PropertyConverter is no longer a >> >> FunctionalInterface >> >> >> :-( >> >> >> >> >> >> shall i fix it or is someone working on it? >> >> >> >> >> >> lg >> >> >> reini >> >> >> > >> > >> > >> > -- >> > *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*
