On 22/07/2011, at 12:46 PM, Luke Daley wrote: > > On 22/07/2011, at 11:55 AM, Adam Murdoch wrote: > >> Looks good. This is a really nice change to the DSL, and I'm tempted to push >> it into m4. > > Cool. This was probably one of the hardest changes to a codebase I've ever > had to make. > >> We should probably rename TaskCollection and PluginCollection to TaskSet and >> PluginSet. > > I do think there is value in being very explicit that these things are sets. > There are also some other ambiguous names in this area I'd like change, the > main one being NameDomainObjectContainer as its name doesn't provide any hint > about it's rules behaviour. > > I'm just going to do what I think is acceptable here, and trust that if I > overstep someone will pull me up. > >> I think it might be good to get rid of these specialisations at some point. >> They don't really add much value. > >> Perhaps we should deprecate TaskCollection.whenTaskAdded() and >> whenTaskRemoved() and PluginCollection.whenPluginAdded() and >> whenPluginRemoved(). > > I wonder if it makes sense to change the methods to whenAdded and whenRemoved > then?
There is DomainObjectCollection.whenObjectAdded() and whenObjectRemoved which do the same thing. I thought about calling them 'whenAdded' and 'whenRemoved' but these names were a bit vague for me, but they're probably ok. > >> I guess at some point (not now) we should think about turning >> NamedDomainObjectSet into a Map. > > I'm not sure about this. I think these things are just sets of things that > have an implicit name. It already behaves like a map (e.g. items as > properties). The one key difference is that with the set approach, the name > is inherent to the object (see the new Namer interface). I think this has > benefits and is actually logically more correct I think. > [snip] > > If we drop the idea of these things being maps as above, we end up with > DomainObjectList extends DomainObjectCollection, then NamedDomainObjectList > with very little work. Sounds good to me. -- Adam Murdoch Gradle Co-founder http://www.gradle.org VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting http://www.gradleware.com
