From: <[EMAIL PROTECTED]> > On Wed, 13 Mar 2002, Jose Alberto Fernandez wrote: > > > That would mean that once a task in a target is resolved to a particular > > definition, > > that definition stays in place. Since in regular ANT each target is > > evaluated only once, > > I see nothing wrong with keeping the invalidation logic ( or maybe I don't > understand all the issues here ). Removing it may not be backward > compatible, so I'm at least -0. ( the invalidate() is not public, but > the behavior should be preserved ) >
The question is whether it would be needed at all. If we do not resolve to a particular task class until just before executing the task for the first time, then the main reason for invalidation (i.e., a definition was resolved before <taskdef> got a chance to execute) will not be an issue anymore. By the time the element gets resolved, your <typedef> would have been executed. The case this do not cover is when we execute the same target several times (not via <ant> or <antcall>) and somehow on each reexecution we change the definition of what the task mean. E.g.: <xxx> is first resolve to "o.a.t.a.t.Copy" the next time to "o.a.t.a.t.Move" , the next time to "o.a.t.a.t.Delete", etc. Now, such mutating behaviour seems to me has no justification. One thing is late binding, but this is self modifying programs. I do not see any use case where people need support for such a behaviour, I actually think it is a bug in the current code to allow such thing. Once a task instance is executed, it should stay committed to its definition. Jose Alberto -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
