<div dir="ltr">BTW other use cases for this sort of thing are automated generation of testing mocks and RPC stubs - things that require a lot of exacting, repetitive drudgery and that no programmer should have to code manually. It's possible to do these with reflection as well, however the problem with reflection is that when you look at the code in the debugger you have to peer inside a lot of obscure data structures to figure out what is going on, whereas it's fairly intuitive to step through generated source code.</div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 9:55 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><span class=""><blockquote type="cite"><div>On Jan 13, 2016, at 6:18 PM, Talin <<a href="mailto:viridia@gmail.com" target="_blank">viridia@gmail.com</a>> wrote:</div><br><div><div dir="ltr">Understood. I might add that one of the advantages of Dagger2 over the older Guice framework is that it does all of the reflection work at compile time, rather than at runtime, so a lot of the expense of runtime reflection is avoided. This also means that the generated code for the injection logic is debuggable, which was historically one of the biggest complaints about Guice.<div><br></div><div>So the bottom line for me is, I don't care as much about the ability to access the attributes at runtime - I'm more interested as to whether the module artifacts output by the compiler can be introspected via some simple API, or are stored in some relatively transparent encoding.</div></div></div></blockquote><div><br></div></span><div>Ah I see, I don’t know anyone considering building those sorts of tools right now.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Chris</div></font></span><span class=""><br><blockquote type="cite"><div><div dir="ltr"><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 5:58 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><span><br><div><blockquote type="cite"><div>On Jan 13, 2016, at 5:24 PM, Talin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div dir="ltr">As a former Googler, I've spent a lot of years writing Java code that uses dependency injection, and this relies heavily on the ability to have custom annotations/attributes in the language - particularly, user-defined attributes on function parameters - and to generate additional code at compile time via annotation processors. Although dependency injection does have it's detractors, it's getting better (current best of breed is <a href="http://google.github.io/dagger/" target="_blank">http://google.github.io/dagger/</a>), and it solves an amazing array of problems, including the ability for asynchronous programming to disappear into the underlying framework - you just write synchronous code and the framework handles the rest (no more futures!).<div><br></div><div>Now, you can of course do dependency injection without custom attribute support in the language, but it's much more cumbersome. The user-defined attributes allow you to specify, in a simple declarative way, the runtime dependencies between various classes. Without it you have to build up those dependencies in code, using some sort of fluent interface or builder pattern.</div><div><br></div><div>So my question is, is there any plan for Swift to support user-created annotations, and annotation processing compilation stages?</div></div></div></blockquote><br></div></span><div>Hi Talin, </div><div><br></div><div>We have no concrete plans for user defined attributes, but it is a natural extension. One of our goals for Swift 3 is to nail down the reflection metadata representation. We should design this to be extensible to support user defined attributes so that we don’t close this off in the future.</div><span><font color="#888888"><div><br></div><div>-Chris</div><br></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div>-- Talin</div>
</div>
</div></blockquote></span></div><br></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">-- Talin</div>
</div>