On 25/07/2011, at 9:07 AM, Adam Murdoch wrote: > On 22/07/2011, at 11:50 PM, [email protected] wrote: > >> Branch: refs/heads/master >> Home: https://github.com/gradle/gradle >> >> Commit: f336c49ec3d1f5300cd7dc6610d784e9641a4e91 >> >> https://github.com/gradle/gradle/commit/f336c49ec3d1f5300cd7dc6610d784e9641a4e91 >> Author: Szczepan Faber <[email protected]> >> Date: 2011-07-22 (Fri, 22 Jul 2011) >> >> Changed paths: >> M >> subprojects/core/src/main/groovy/org/gradle/api/internal/plugins/AbstractConvention.java >> M >> subprojects/core/src/main/groovy/org/gradle/api/internal/plugins/ExtensionsStorage.java >> M >> subprojects/core/src/main/groovy/org/gradle/api/plugins/ExtensionContainer.java >> M >> subprojects/core/src/test/groovy/org/gradle/api/internal/plugins/ExtensionContainerTest.groovy > > ExtensionContainer is starting to look very much like a > NamedDomainObjectContainer. Perhaps we should change it to extend > NamedDominObjectContainer, so that we pick up some DSL goodness (eg > notifications, rules, can use extensions.name in expressions, and so on). We > can also get rid of ExtensionsStorage, as DefaultConvention can just extend > DefaultNamedDomainObjectContainer. > > It might also be good to hoist some methods up to DomainObjectCollection: > * <T> T getWithType(Class<T> type) > returns the object with the given type, or fails if there is no such > object, or multiple such objects. > * <T> T findWithType(Class<T> type) > returns the object with the given type, or null if there is no such > object, or fails if there are multiple such objects. > * Perhaps also <T> T getAt(Class<T> type) > so we can using container[type] in expressions. Same behaviour as > getWithType() > > I can see these being generally useful (they're already present in > PluginContainer, for example).
Seconded, JIRA? -- Luke Daley Principal Engineer, Gradleware http://gradleware.com
