Community
Participate
Working Groups
Build Identifier: Version: 3.7.1 Build id: 20110909-1335 Proposal for adding annotation @Dispatch(or something similar) to dispatch method definition in generated Java code, so that Java code reader can distinguish them from normal non-multi-dispatchable methods, since they are different from the view point of caller. Reproducible: Always
They start with an underscore isn't that suffcient?
Other elements that are generated also start with an underscore. @Dispatch would be more descriptive in addition to the mandatory underscore prefix. +1
Currently we automatically pick up operations from Java superclasses that have the right signature (start with '_', have correct # of args) when assemblying the dispatch case methods. Adding a @Dispatch annotation suggests that these are no longer taken into account. This could break existing clients.
I don't propose to change the semantics of the _underscore methods but just to add the annotation for documentation purpose. Alternatively we could append that information to the JavaDoc.
It has been a while so I cannot remember the exact scenario this ticket was brought up. The gross motivation was that I wanted to reflect on some Java classes (yes, including Xtend generated ones) and list their members, including fields and methods. And I found that Xtend dispatch method generates a group of methods which should be non-exist from the view of programmer, so I want to hide these "phantom" methods from the user of my module. However I found this difficult, because there is no ensured way to tell if an _underscore leaded method is a generated dispatch method, or it is just a hand-written private method. I know that this "_privateThings" style is becoming obsolete, however in our code base it exists. And there is no requirement defined in Xtend that require user to abandon _privateElement style. And even if it do, I don't think this requirement reasonable. So it makes the above objective impossible. There is a principle saying: make easy things easy and hard things possible. Thus, may I go a step further and suggest that everything "virtually" generated by Xtend(that is, not exist in Xtend source code, meaning that they shall be invisible to programmers in conception) be tagged with @XtendGen annotation, in which an enum value used to distinguish concrete cases. enum XtendGenType { METHOD, FIELD, ... // Could be more specific, e.g. DISPATCH_METHOD } And in generated java code: @XtendGen(XtendGenType.METHOD) _dispatchMethodImpl() {... IMHO it costs almost nothing and don't get in the way when it isn't needed. And there is no difficulty in implementation. And though the case is rare, it may make some runtime reflection problems possible.
In addition to the mentioned use cases for Java reflection, I see the following advantage for a dedicated @Dispatch annotation: Iff we annotate the cases / all synthetic members properly, this information will be displaced in the JavaDoc, e.g. @Dispatch _caseSomething instead of _caseSomething. Furthermore I expect findbugs to be able to suppress certain validations if a specific annotation is present. One could even go a step further and provide a JavaDoc template that is aware of a @Dispatch Javadoc tag and highlights / groups these methods correctly.
