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. (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 +=. Cheers, Peter -- View this message in context: http://gradle.1045684.n5.nabble.com/New-Test-Logging-tp5709881p5709905.html Sent from the gradle-dev mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
