Hans Dockter wrote:
On Aug 8, 2008, at 9:11 AM, Adam Murdoch wrote:
Hans Dockter wrote:
Hi,
our public API interfaces like Project are used by two different
groups. One group are the Gradle users when writing there build
script as well as our plugins. The other group are internal classes
like BuildConfigurer. Some of the API is only used by the latter
(e.g. the evaluate method of the Project interface). So I think it
would be a good idea to add an interface like ProjectInternal, which
extends Project, for this part of the API.
I was thinking the same thing as I was writing javadocs (the methods
on Project without javadoc are pretty much the ones I reckon belong
elsewhere).
I'd almost add a 3rd group of methods, which are the methods that add
the groovy DSL to the java API - eg Project.task(name, closure).
These are all really just convenience methods for the core API
methods. I wonder if these belong on another interface which extends
Project? That way another DSL can have its own interface independent
of the groovy one.
I think this is a good idea if we stick to the current design (see my
comments below). We might call this interface GroovyProject.
There are also some methods on the implementation classes of
interfaces like Project which would be good to add to an API
interface somewhere - mainly so they can be documented. These are the
groovy DSL variants of other methods already on the API, eg
Project.dependencies(closure) or createTask(..., closure).
Wouldn't be GroovyProject the place to put them (for the Project
methods)?
It would be. I might add them to Project (with javadoc, of course)
until we decide what to do with the groovy stuff, so they can be documented.
In the beginning we had simply a DefaultTask and a DefaultProject
class to implement our Project and Task interface. Then we decided
that to improve performance and for some other reasons we want to
implement as much as possible in Java. We did this pretty much in a
rush. The current state is not as concise as I would like it to be.
One may define three layers for this space:
1.) Java classes which use only other java classes
2.) Java classes which use also Groovy classes
3.) Groovy classes
To objective for separating the layers 1.) from 2.) and 3.) is to
separate the pure Java core from a specific DSL. This separation adds
complexity to the design (e.g. introduction of Action classes)
although right now we have only one DSL language. We don't know when
we start to develop an engine for another DSL language and what
exactly the requirements for this would be. I think the current
separation smells a little bit like 'speculative generality'. I'm
wondering if we should merge this layers again. Also this layerign is
only partly implemented.
What would the merged layers look like? What would you change?
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
