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? > >> > 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. 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! > >> > 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. > > > > > > > >> > >> > -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*
