ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: [PATCH] myrmidon task configurer
Date Sun, 30 Dec 2001 11:43:54 GMT
On Sun, 30 Dec 2001 14:32, Adam Murdoch wrote:
> Hi,
> This is a patch to myrmidon's task configurer, to cache reflection info.
> The goal was to start playing with some new configuration features, but
> unfortunately I didn't find time to do much with it.  I'd like to put this
> on hold temporarily, so I'm submitting the changes as they currently stand.
> Configuration should be heaps faster now.

excellent - will commit the changes next time I reboot - prolly sometime 
tomorrow or maybe wendsday given it is new years eve tomorrow ;)

> Here's what I'd like to try sometime soon-ish:
> * Allow an object (task or data type) to override parts of its
> configuration process.
> This would be an alternative to implementing Configurable (which requires
> the object to deal with configuring itself entirely).

It should be possible for a task or any object to only have it's subelements 
Configurable and where that is not the case there will be a base utility 
class (see AbstractTaskContainer) to help do the configuring. This utility 
class will allow the task to call back into the configurer to do the 
configuring. AbstractTaskContainer is not real easy atm but it sort of shows 
what I was aiming at. 

WOuld this be enough for you ?

> The plan is to allow a class to provide a customised introspector (an
> ObjectConfigurer) via a static method - getConfigurer(), say.  This would
> allow a class to do simple things like:
>   - Explicitly choose an overloaded setter/adder/creator method to use when
> there's more than one.
>   - Ignore certain setter/adder/creator methods.
>   - Map text content to a particular attribute (e.g. "message" in the <log>
> task).

I think all of the above should be done via some sort of TaskInfo object.

>   - Deal with attributes or elements whose names are only known at runtime
> (e.g. compiler adaptors).

This is something that still needs to be figured out. Hopefully the above 
utility class would be enough to make this easy.

> * Deal with references.
> Have the configurer resolve (and type check) references to data types,
> rather than forcing the object do it.  An adder method would be passed an
> object, and whether that object was obtained by reference, or created and
> configured inline, the parent object doesn't know or care.


The two ways I proposed for doing this were basically recognizing some magic 

One construct would be that any element/attribute name that ended with "-ref" 
would have the "-ref" part removed and the normal attribute/element 
configuration process would proceed except that it would use the reference.

The other constrct is just recognizing the case where an element has one 
attribute named refid and treat it specially.

I favour the first method as it deals with attributes and elements and is 
generally easier IMHO but the second method is more standard to our current 

What do you think?

> This raises the issue of ownership, and immutability - maybe a clone gets
> passed to the adder methods.

Hmmm .. haven't really though much about this but to fit in with the rest of 
the model you probably should not be passing a clone...

> * Polymorphic types.
> This was raised a few months ago and it is truely an excellent idea.  This
> would allow the configurer to pass an adder method, an object of any class
> that is assignable to the declared type.  As Peter pointed out, this would
> neatly solve the adaptor problem that is being discussed.


> * Lifecycle management.
> It would be handy if the lifecycle of nested objects was handled by the
> container, rather than forcing the parent object to do it.  Not the
> configurer's job, necessarily.

Can you give a use case for this?

> * Put some tests together, and maybe some docs as well (yeah sure).




"Sometimes its better to keep your mouth shut and 
let people think your an idiot, than to open it 
and remove all doubt." 

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

View raw message