On 18/06/2012, at 9:27 PM, Peter Niederwieser wrote: > > Hans Dockter-2 wrote >> >> 1.) The events(Object... events) is not additive but replaces existing >> values. This is different to the behavior in other parts of the Gradle >> DSL. >> It confused me a little bit when I used the events method together with >> some of the alternative configure methods (e.g. showStandardStreams). >> > > I reasoned that in the case of test events, one would usually want to > override, and hence chose this as the method's behavior. If the method's > behavior was additive (like it was in the beginning), one would have to > write `events = [TestLogEvent.PASSED]` instead of `events "passed"` to see > just `passed` events. This is because lifecycle and debug levels have > non-empty defaults. The fact that I once was perplexed that `events > "passed"` still gave me `failed` events convinced me to change the behavior > to overriding. > > This reflects the general problem that in our DSLs, often only the > (additive) method is convenient to use, and there is no convenient way to > get overriding behavior. A partial solution would be to make the setter > accept Set (or Object) rather than Set<TestLogEvent>. This would allow to > use strings instead of enum values, but would still require a list literal > (plus more sophisticated type conversions). I haven't checked if Gradle is > happy with getter and setter having different types. > > Note that I used the test logging DSL as an initial test bed for how our > configuration DSLs could look like in the future (in terms of type > conversions and (auto-generated) convenience methods). Regarding the add vs. > override problem, I can think of the following solutions: > > * Setter always overrides, method always adds (more or less what we do > today). For this we should make the setter as convenient to use as possible > (in particular regarding type conversions). Won't get around having to use a > list literal though, which is somewhat ugly. > > * User has a generic way to specify whether a method has additive or > overriding behavior. Something like: `events "started", "failed", override: > true` > > * DSL author can select on a case-by-case basis whether the (auto-generated) > method is additive or overriding
I don't think it's a good idea that a given syntax sometimes adds and sometimes replaces. This behaviour needs to be consistent everywhere. So I would say option 3 is out. The type conversion stuff we definitely want, regardless of what the add/replace syntax ends up looking like. Another option (or more a variant of 2 above) is to drop the method entirely, so that you can do either: prop = ['a', 'b', 'c'] or prop += ['a', 'b', 'c'] And that's it. In other words, the groovy language already has some generic mechanisms for adding and replacing, and things might be simpler if we just made use of them (we've got to support people using them anyways). Personally, I think it's the type conversion where the value is here, rather than tweaks to the syntax. The syntax is fine as it is, and I wouldn't go changing it until we have a clearly better replacement. I'd rather not have the list literals, but there are much bigger usability wins out there for us. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
