On 21/05/2012, at 6:52 AM, Luke Daley wrote:
>
> On 20/05/2012, at 9:42 PM, Adam Murdoch wrote:
>
>> On 20/05/2012, at 11:18 PM, Luke Daley wrote:
>>
>>> Should we add this as the public typed API for getting the
>>> ExtensionContainer of decorated objects?
>>
>> This doesn't really have much to do with a Project. I'd rather not treat
>> Project as a bucket of utility methods.
>
> Fair call.
>
>> ExtensionAware already exposes this information in the public API. Do we
>> really need a static method to wrap a cast for you?
>
> I think so, just for error reporting. An exception saying that the object is
> not ExtensionAware would be better than a ClassCastException.
Maybe. The message you get from a ClassCastException says pretty much the same
thing, from java 6 onwards.
>
> We've got the same problem for IConventionAware (when it goes public) &
> DynamicObject if that's going to be public at some point.
Indeed. And for anything we dynamically mix in but that is really static in
nature, such as extensions, or the DSL mapping. It would be nice to have a
static view for this stuff somehow.
For example, it would be nice if we could automatically generate something like
this from the JavaPlugin:
interface JavaProject extends Project, ExtensionAware, ConventionMappingAware {
JavaPluginExtension getJava();
void java(Closure cl);
}
Then, another plugin could implement Plugin<JavaProject> instead of
Plugin<Project>, and Gradle would infer that the Java plugin needs to be
applied and a Java-domain-specific view of the Project provided. This would be
a nice way to decouple the API + implementation of plugins.
Same for other domain object types, where we statically mix in some of the
dynamic stuff. This might grow so that the entire DSL mapping (which is also
static) is mixed in. This would be very helpful for content assist in the IDE,
for example. It would also allow alternative DSLs for static languages to be
developed.
Not entirely sure how to implement something like this in a way that's
convenient for use in the IDE. There's really only 2 broad approaches I can
think of:
* Mix the stuff in to the target classes.
* Generate subclasses that mix the stuff in.
This is true for dynamic implementation, too, so we're really talking about
moving the decoration from runtime to somewhere earlier in the development loop.
--
Adam Murdoch
Gradle Co-founder
http://www.gradle.org
VP of Engineering, Gradleware Inc. - Gradle Training, Support, Consulting
http://www.gradleware.com
