2015-01-20 17:40 GMT+01:00 Anatole Tresch <[email protected]>: > Hi Romain > > see inline. > > 2015-01-20 17:29 GMT+01:00 Romain Manni-Bucau <[email protected]>: > >> 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. > > > I dont get the point. Again, please answer my questions. > > How do you want to evaluate the target type a converter is targeting > during registration? >
answering in next answer > > >> >> > 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> >> >> ? >> > > Simple because you dont have that information at runtime in Java 7. > oops so CDI is fully broken. Of course you have it - even in java 6. > > 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 >> > Already stated this will not work in all cases. Try thinking doing it > alternately please. > > 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 > > Combined with 1, this makes no sense. When I have the information from a > reliable source (1 is not reliable) and dont need 2, if I cant do it, I can > go home and cry or just look for a soliution, I will not do things more > simpler, just because of simplicitly. Reduce to the max, but not one step > further! > You didnt get me: I'm not opposed to @ConverterType or whatever name it is, I'm opposed to force it cause it makes super verbose classes for nothing + in 80% of the cases (100 in our impl IIRC) it is redundant. > > >> >> > 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 >> > > Not true! 1 and 2 is exactly the same in Java 7 and 8. > > > >> 2) that said this confirms what is said before: you dont need this >> getTargetType() > > > As already said, useless to comment. It will not work as you suggest. > I fear you don't know java reflection API enough here, or I am really missing something important but I dont get yet what > >> > >> > >> > >> >> >> >> > -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* >> > > > -- > *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*
