<div dir="ltr">Why not making all Annotated* mutable during boot lifecycle?<div><br></div><div>Would allow to get rid of the annotated root in the modification code, for instance we could convert:</div><div><br></div><div> <span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)">type.getMethods().stream().filter(m -> m.isAnnotationPresent(Foo.class)).forEach(m ->event.setAnnotatedType().addToMethod(m, MyInterceptor.BINDING));</span></div><div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)"><br></span></div>to<div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)"><br></span></div><div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)"> </span><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)">type.getMethods().stream().filter(m -> m.isAnnotationPresent(Foo.class)).forEach(m -> m.mutate().add(MyInterceptor.BINDING));</span></div><div><span style="color:rgb(44,45,48);font-family:Slack-Lato,appleLogo,sans-serif;font-size:15px;line-height:22px;background-color:rgb(249,249,249)"><br></span></div>or if we don't want to add mutate in the existing types we could use configurator as root for type type and recreate a Configurator graph matching annotated graph.<div><br></div><div>Advatage is first code i a bit awkward in the sense you can call setAnnotatedType() multiple type (what would happen? only last modification will be saved? or you have to keep a reference to the configurator once called which breaks the fluent API provded by streams IMO.</div><div><br></div><div>wdyt?</div><div><br></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><br><span style="font-size:small">Romain Manni-Bucau</span><br><a href="https://twitter.com/rmannibucau" target="_blank">@rmannibucau</a> | <a href="http://rmannibucau.wordpress.com" target="_blank">Blog</a> | <a href="https://github.com/rmannibucau" target="_blank">Github</a> | <a href="https://www.linkedin.com/in/rmannibucau" target="_blank">LinkedIn</a> | <a href="http://www.tomitribe.com" target="_blank">Tomitriber</a></div></div></div></div></div></div></div></div></div></div>
<br><div class="gmail_quote">2016-02-05 15:24 GMT+01:00 Antoine Sabot-Durand <span dir="ltr"><<a href="mailto:antoine@sabot-durand.net" target="_blank">antoine@sabot-durand.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hi all,</div><div><br></div><div>Following discussion during last meeting, I rewrote most of my PR for builders.</div><div><br></div><div>We now have 2 clean and distinct ways of using them</div><div><br></div><div>1) in DSL style (with a Configurator interface without build() method)</div><div><br></div><div>public void processAT(@Observes ProcessAnnotatedType<?> pat) {</div><div> pat.setAnnotatedType().read(pat.getAnnotatedType()).addToType(new AnnotationLiteral<MyInterceptor>() {};);</div><div>}</div><div><br></div><div><br></div><div>2) In classical reusable builder mode (builders extends configurator and only add build() method)</div><div><br></div><div><div>public void processAT(@Observes ProcessAnnotatedType<?> pat) {</div><div> AnnotatedTypeBuilder atb = Builders.annotatedTypeBuilder();</div><div> atb.read(pat.getAnnotatedType()).addToType(new AnnotationLiteral<MyInterceptor>() {};);</div><div> pat.setAnnotatedType(atb.build());</div><div>}</div></div><div><br></div><div><br></div><div>As Configurators don't have build() method there's no risk that users mix them with standard builders.</div><div>For clarity sake, builders are no more available in lifecycle event but in Builders class for consistency.</div><div><br></div><div>I'm quite happy with the result, but I'm sure you'll have comment ;). So thanks for your feedback</div><div><br></div><div><a href="https://github.com/cdi-spec/cdi/pull/270" target="_blank">https://github.com/cdi-spec/cdi/pull/270</a><span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>Antoine</div></font></span></div>
<br>_______________________________________________<br>
cdi-dev mailing list<br>
<a href="mailto:cdi-dev@lists.jboss.org">cdi-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/cdi-dev" rel="noreferrer" target="_blank">https://lists.jboss.org/mailman/listinfo/cdi-dev</a><br>
<br>
Note that for all code provided on this list, the provider licenses the code under the Apache License, Version 2 (<a href="http://www.apache.org/licenses/LICENSE-2.0.html" rel="noreferrer" target="_blank">http://www.apache.org/licenses/LICENSE-2.0.html</a>). For all other ideas provided on this list, the provider waives all patent and other intellectual property rights inherent in such information.<br></blockquote></div><br></div>