ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject Re: IntrospectionHelper request
Date Wed, 09 Jan 2002 11:26:12 GMT
On Wed, 9 Jan 2002 19:40, Jose Alberto Fernandez wrote:
> In any case, when I write a Task that can have elements that are tasks
> (TaskContainer) or one that can have mappers, there should be no difference
> from the task writer point of view on how to write its set/add methods. Of
> course it may be that for a TaskContainer the argument is not ot type Task,
> but some other thing like a TaskModel that you mention and I am not sure I
> understand. But the point is that whtever it is, it should be based on the
> same discovery mechanism that you describe for the other <roles>: "based on
> the "add" method signature, reverse map to a role and then search on the
> role's registry for an entry for the corresponding element".

Well what I am saying there is essentially two ways to get extensibility. 

1. The first way is to get passed the TaskModel and interpret it yourself 
(probably using the services from the container). 

2. The second way is via the normal reflection process where an element is 
allowed to have a generic

void add( SomeInterface myInstance );

which can be used to add arbitrary subclasses of the interface 

(1) is needed because (2) does not allow enough flexability and there is no 
reliable way to have multiple add( MyInterface ) methods in an element. If 
you can think of a way to get rid of (1) then I am all ears but I think you 
would be hard press to.

In any case TaskContainers need to be treated differently as no task can ever 
get access to another Task instance - they only operate on the TaskModel. 
(They pass the TaskModel to the container which executes the Task).



| Wise men don't need advice. Fools don't take it. |
|              -Benjamin Franklin                  |

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

View raw message