I think you are right, and having only @NamedVariant on a method should equal also having @NamedParam on every parameter. Rationale: I feel it is the more common case & least surprise, adding @NamedParam to all arguments is cumbersome and creates a lot of clutter/noise, and (as you said) making the @NamedDelegate case explicit is a good idea. +1 on changing this.
-------- Ursprüngliche Nachricht --------Von: Paul King <[email protected]> Datum: 04.09.18 10:17 (GMT+01:00) An: [email protected] Betreff: Proposed @NamedVariant breaking change edge case Hi folks, I have been thinking about: https://issues.apache.org/jira/browse/GROOVY-8703 If you remember the design behind @NamedVariant, there weretwo schools of thought. One group were keen on always having the firstparameter as a delegate; it's properties determining the keys for named args.Another group were keen on the names of the params themselvesbeing the keys for named args. Our current design using @NamedParamand @NamedDelegate market annotations covers both these use casesand even allows mix and match. I don't plan on changing anything in cases where either @NamedParamor @NamedDelegate are used, however, I think I made the wrong call forwhat should happen if no marker annotations are placed on the parameters.I went with defaulting the behavior as if @NamedDelegate was implicitlyadded 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 @NamedVariantuptake won't be huge at this point and most probably folks aren't relying onthe behavior when the additional marker annotations are left off.I propose we change this behavior and list it as a breaking change inthe 2.5.3 release notes. If we delay any longer though, I think we will needto stick with the current design. We could add an autoDelegate annotation attribute to allow the old behaviorto be switched on but I think in fact using @NamedDelegate on the firstparameter is actually clearer anyway. I guess for annotation collector scenariossomething like autoDelegate might be useful. Thoughts? Cheers, Paul.
