sounds like a good idea. For extensions there's already a ticket. I can look at the extension stuff in between the tooling api stuff.
Cheers! On Mon, Jul 25, 2011 at 2:09 AM, Luke Daley <[email protected]> wrote: > > 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 > -- Szczepan Faber Principal engineer@gradleware Lead@mockito --------------------------------------------------------------------- To unsubscribe from this list, please visit: http://xircles.codehaus.org/manage_email
