Hi folks, I have been thinking about:
https://issues.apache.org/jira/browse/GROOVY-8703 If you remember the design behind @NamedVariant, there were two schools of thought. One group were keen on always having the first parameter as a delegate; it's properties determining the keys for named args. Another group were keen on the names of the params themselves being the keys for named args. Our current design using @NamedParam and @NamedDelegate market annotations covers both these use cases and even allows mix and match. I don't plan on changing anything in cases where either @NamedParam or @NamedDelegate are used, however, I think I made the wrong call for what should happen if no marker annotations are placed on the parameters. I went with defaulting the behavior as if @NamedDelegate was implicitly added to the first param. In fact, I think it should have been as if @NamedParam was added to all parameters. Basically, I propose making this (using the GROOVY-8703 example): @NamedVariant Color(Integer r, Integer g, Integer b) { this.r = r; this.g = g; this.b = b } Be the same as this: @NamedVariant Color(@NamedParam Integer r, @NamedParam Integer g, @NamedParam Integer b) { this.r = r; this.g = g; this.b = b } Given 2.5 has only been out for a few months, I suspect @NamedVariant uptake won't be huge at this point and most probably folks aren't relying on the behavior when the additional marker annotations are left off. I propose we change this behavior and list it as a breaking change in the 2.5.3 release notes. If we delay any longer though, I think we will need to stick with the current design. We could add an autoDelegate annotation attribute to allow the old behavior to be switched on but I think in fact using @NamedDelegate on the first parameter is actually clearer anyway. I guess for annotation collector scenarios something like autoDelegate might be useful. Thoughts? Cheers, Paul.
