ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam Murdoch" <>
Subject [PATCH] myrmidon task configurer
Date Sun, 30 Dec 2001 03:32:39 GMT


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.

Here's what I'd like to try sometime soon-ish:

* Allow an object (task or data type) to override parts of its configuration

This would be an alternative to implementing Configurable (which requires
the object to deal with configuring itself entirely).

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>
  - Deal with attributes or elements whose names are only known at runtime
(e.g. compiler adaptors).
  - etc.

* 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.

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

* 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.

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


View raw message