<div dir="ltr">You can say that about any metaprogramming feature, including operator overloading, parametric polymorphism, automated code generation, or any other form of programmable syntax - all of these features have to be used with care because they essentially create new dialects of the language. As for using annotations to drive dependency injection, this is used by thousands of Google engineers on a daily basis and people generally find it quite powerful and helpful. I actually think it is syntactically less dangerous overall than the ability to invent new infix operators, because at least you have an imported name that you can search for.<div><br></div><div>My own personal interest is in metaprogramming, that is "code that operates on code", whether it be by reflection, template instantiation, or automated code generation. In Java, this is sometimes done through reflection, and sometimes via annotation processors, which are plugins to the Java compiler that can examine the annotations and generate additional helper classes. By contrast, in my own experimental language, the output of the compiler is stored in a generic introspectable binary file format, similar to protocol buffers, which can easily be taken apart and re-assembled by any programming language (C, Python, Swift, Go, etc), allowing any sort of post-processing on a compiled module.</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 13, 2016 at 10:01 PM, Yang Wu <span dir="ltr"><<a href="mailto:pinxue@gmail.com" target="_blank">pinxue@gmail.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">-1 on user-created annotation.<div><br></div><div>I wrote Java since 90s and hate user-created annotation. Annotation is indeed a backdoor in syntax system, it makes source code totally un-understandable before you read reference of the annotation. </div><div><br><div><blockquote type="cite"><div><div class="h5"><div>在 2016年1月14日，上午9:24，Talin via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 写道：</div><br></div></div><div><div><div class="h5"><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><br></div><div>-- <br><div>-- Talin</div>
</div></div>
</div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=zv-2Fta8zZnJ-2BWwISX5RHdd79su-2FjoebtLz43a4s-2BYOw2dFnGHA6hubqjnE5OiPSOfPaxRKCLiOtFMH8SSdkVT3kXGBcYuebI7S5Bu02a0JrGQqXOKG5TKnFavYaPtktlGbgAv0vywouzVXIQTNNs-2FV-2B7iruxb9VHOUZ8ShyQknyda-2FJMr-2FrPVYcCz6uaNnY5KaJ75Elvw9QL0WdO0pAwDhitTGSz-2B6hT70hkos-2F8sNd0-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div><br></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">-- Talin</div>
</div>