ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <>
Subject Re: svn commit: r451000 - in /ant/core/trunk/src: main/org/apache/tools/ant/taskdefs/ main/org/apache/tools/ant/taskdefs/condition/ tests/junit/org/apache/tools/ant/
Date Sun, 01 Oct 2006 20:45:47 GMT
On 9/29/06, Peter Reilly <> wrote:
> Or maybe we could implement a "mixin" method protocol:
> void antMixin(ConditionBase x) {
>   this.condition = x;
> }
> This would be usefull for types/tasks that share common attributes but
> do not want to use java's single inheratance to get the attributes/nested
> elements.
> For example the matches condition has regex attributes (singleline,
> multiline, casesensitive),
> pattern and nested regex. There could be given to a mixin class -
> RegexMixin, this could be shared with other types/tasks.
> void antMixin(RegexMixin x) {
>   this.regexParams = x;
> }

That would be *fantastic* Peter!!!

So I could declare several mixin methods, antMixin(FooMixin),
antMixin(BarMixin), and when faced with an otherwise un-recognized
attribute or nested element, it would use IH on the mixed-in types
FooMixing and BarMixin to see if any of these supports the unknown
attribute or nested element?!

Overlap in attr/elem between the main type and the mixins would be
silently ignored (maybe a warning a warn or debug level only), the
main type taking precedence; but overlap in attr/elem between the
mixins would be an error (ambiguous).

I created a bunch of conditional tasks or types, which made use of a
single ConditionSupport class, but I still had to expose of the
attributes from ConditionSupport in the tasks/types themselves, when I
couldn't inherit from it. The mixin solution would have elegantly
solved this.

I *really* look forward to mixins! --DD

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message