From: "Stefan Bodewig" <[EMAIL PROTECTED]>

> On Sat, 9 Mar 2002, Jose Alberto Fernandez <[EMAIL PROTECTED]>
> wrote:
> 
> > The only special case is with "id" references that would have to be
> > resolved when they are used, (if not resolved yet).
> 
> This could be done (by returning a smart replacement for Hashtable in
> project.getReferences in the first place) and you'd still have to
> resolve all references when you encounter a script task, but it would
> probably work.
> 

I agree.

> > If we could a consensus on how to do that we could reduce
> > ProjectHelper cruft by at least 80% (at least in the version in
> > <antlib> proposal) and we would finish with a completely regular set
> > of rules for constructing and evaluating the tree.
> 
> So let's try to get consensus here.
> 
> As far as I can tell, the only reason to have task instances created
> at parser time are references.  If nobody else can come up with a
> different reason and we can address this issue, we have consensus, no?
> 

Yes. I was looking at the code in <antlib> today and I agree that 
UnknownElement is 
preaty bad. What I want to achieve is a very regular mechanism for doing the 
parsing.
If you look at <antlib> you will see that Top level tasks are treated as just 
being
inside a special kind of Target which is evaluated inmediately. That means that
all parsing code behaves as inside a Target. 

If we can get rid of the bookeeping to invalidate tasks, that would be 
fantastic.
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 no issue here (multiple execs via <antcall> use reparsing). The only case 
in which
multiple execs of a target are possible is via <script> and in that case I am 
not even
clear if you really get tasks resolved every time. I think this is such a funny 
ussage
that we can really forget about it.

Does any one has a counter example?

Jose Alberto




--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>

Reply via email to