ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dominique Devienne" <ddevie...@gmail.com>
Subject Re: Mixins for Introspection
Date Mon, 02 Oct 2006 13:30:12 GMT
On 10/2/06, Peter Reilly <peter.kitt.reilly@gmail.com> wrote:
> > >That would be *fantastic* Peter!!!
> It would be nice to have. I have no
> code but suspect that IH would hit new Complexity Limits.

Are you refering to a particular code metric? or saying this in general?

I personally think IH could be slimed down but extracting one or two
utility classes out of it, and that adding mixins, while undoubtly
adding some complexity, should be manageable.

> > >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;

> Hard to know what is the best approach -whine or ignore?

As stated, I'm more for ignore, with a little whine at DEBUG level.

> > You could also pass the value to both: the task and the mixin.
> Mmm.. I do not think so - too much scope for bugs.

I don't like that either.

> public class MyMixin /* extends PC/some baseclass? */ {
> PC I think, to get location,and loging -  just Object should work as well.

Yes, ideally any object could be used, but I have no problem with
forcing Mixins to be at least ProjectComponents. This may indeed
simplify implementation and would likely improve error handling. Once
(and if) PC-based mixins are out-in-the-wild and succesful, we could
revisit the restriction to be a PC, if necessary.

> > <mytask foo="bar"/>
> > -->  MyTask.foo       = "bar"
> > -->  MyTask.mixin.foo = "bar"

I'm not fond of this idea. Somebody doing MyTask.setFoo("baz")
programmatically will wonder why somehow the behavior of MyTask is
influenced by a "bar" somewhere, despite the setFoo("baz"). Violates
the principle of least surprise IMHO.

> > Another possibility would be setting the back reference automatically
> > public class MyMixin {
> >     Task caller;
> >     public void setTask(Task c) { caller=c; }
> > }

I view mixins are reusable bits of code to be used by tasks/types, and
I'm not sure I want the mixin to be aware of its container at all. In
any case, a mixin that wants to know about its container can always
define its own ad-hoc documented protocol, but defining a setTask-like
method, and documenting that the container should call it. Let's keep
IH as simple as possible regarding mixins IMHO.

> I would rather have annotations, [...] but that will not happen, so
>   void antMixin(RegexParams ..)
> will have to do for the moment.

Regarding the name, what about composeMixin(Type t)?
I would like to emphasis mixins should be used for composition.

> Note that antMixin will always be called, even if the no attributes or
> nested elements are set

That's fine. Better that than null-checks everywhere. People that will
use mixin probably just like me used pure composition already, with
the trouble of having to expose all the set/add methods of the
composed types, so it's basically the same.

> alternatively other naming convenetions could be used:
>  private RegexParams  antMixinRegexParams;

Since we don't have antAttributeFoo, or antElementBar, lets not go there.

>  RegexParams getAntMixinXXX()
> (where XXX is ignored by IH, but can ge used to have multiple mixins).

I prefer the semantic of antMixin(Type t), which allowed polymorphic
behavior, and already supports multiple mixin types thanks to method
overloading.

>  Object[] getAntMixins()

Again that would prevent polymorphism, and is less Ant-ish.

--DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message