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/

[Dominique Devienne <dd...@gmail.com>]

On 9/29/06, Peter Reilly <pe...@gmail.com> 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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org