On 26/06/2012, at 11:35 PM, Peter Niederwieser wrote: > > Adam Murdoch wrote >> >> 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. >> > > Syntax may not be the most important, but many of our APIs already support > method syntax (and we add some methods on the fly), it's convenient to use > and reads nicely. Therefore, the best compromise might be to make method > always mean addition, and have setters support the same type conversions as > methods. This would mean that only the getter has the canonical property > type which type conversion will be based on.
Exactly what I was thinking. It's more or less what we currently do, with some additional type conversion goodness. > (Maybe we could add an overload > for the setter with canonical type; not sure.) > > I'm not completely convinced that we need to support +=. We would gain some > freedom over how addition works, and what exactly it means, by not > (universally) supporting +=. We need to understand it eventually, for the purposes of convention mapping. That gives us some opportunities for applying the type conversion for this as well. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
