I like the push-buttons API concept. But I wonder if we are violating this concept with for e.g. the AbstractDependencyManager (Java class) and the DefaultDependencyManager (Groovy class that extends the abstract Java class) and the Groovy class takes care of the property/method missing logic. If I get the push-button API concept than the DefaultDependencyManager should not extend the AbstractDependencyManager but should delegate to it (ignoring the abstract part here for the moment). I think that would create a very clean separation of what is part of the actual API and what is done to be able to process the script.
2008/12/27 Hans Dockter <[email protected]> > I had a first in-depth look at the material Martin Fowler is collecting for > his future DSL book. It is very good stuff (again and again). > > http://martinfowler.com/dslwip/ > > I provides us with a terminology for our different DSL constructs. From > reading all this, I think we are on a good track. Yet there is one smell we > have, from what is explained there. Usually we have a separate Groovy object > which adds the DSL goodies to our API. In Martin Fowlers terms, this Groovy > object is an 'Expression Builder' providing a 'fluent interface' on top of > our 'push-buttons API'. But in some of our 'push-buttons API' we have also > element for a 'fluent interface'. Martin Fowler recommends that this is > strictly separated (with some exceptions that don't apply to us). We have > this future plan, to ship also a Java build script engine. But we probably > shouldn't bother in our Java API about this, but add a Java Expression > Builder on top. It might make sense that the Groovy Expression Builder > inherits from the Java Expression Builder. > > - Hans > > -- > Hans Dockter > Gradle Project lead > http://www.gradle.org > > > > > > --------------------------------------------------------------------- > To unsubscribe from this list, please visit: > > http://xircles.codehaus.org/manage_email > > >
