Hans Dockter wrote:
On Nov 7, 2008, at 9:33 PM, Adam Murdoch wrote:
In addition, I think consistency is important here. Settings, Project
and Task all have dynamic properties and/or methods, but they all
work a little differently, and the methods on the interfaces are not
quite the same (setProperty vs defineProperty). I'd rather not have
to keep a different set of rules in my head for each type of
extensible thing.
Definitely. But we have run into a Groovy pecularity here. For any
Groovy object setProperty is automatically added. You can overwrite
this but this gets not inherited. Therefore the way we use it works
for projects, as we only use the default project. But it does not work
for tasks as the tasks inherit from DefaultTask where setProperty is
overwritten. So I guess we have to rename the setProperty method of
the Project class.
I've been doing some experimentation with this. It looks a groovy object
does not inherit setProperty() from a java superclass. However, a groovy
object does inherit it from a groovy superclass, and a java object
inherits it from either type of superclass. Interestingly,
propertyMissing() and methodMissing() are inherited from a java
superclass. I'm not sure if this is a bug or feature.
So, provided the public Task implementation that people extend is a
groovy class, it should be fine to call the method setProperty().
However, if we use setProperty(), should we use getProperty() as well,
instead of property(), for consistency? That is, should we use the
groovy names for these methods, or should we invent our own parallel ones?
I think we should use the groovy names. However, I guess we could
potentially be setting ourselves up for some problems in the future by
doing this.
Adam
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
