ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chr <>
Subject RE: [PATCH] Nested Tasks
Date Mon, 29 Jan 2001 10:38:48 GMT

Thank you for your competent feedback.

>I think we need to have a debate about whether nested tasks is a desirable
>concept to implement. Whilst I can see how it might be desirable for your
>approach to multithreading, it can open up a Pandora's box of complexity. I
>don't think the debate last time was conclusive.
>Anyway, ignoring those concerns, let me give you some feedback on your
>patch. Firstly, please update to the latest version from CVS before doing
>your diff. I am not sure how you have done it but the patches you have
>submitted would undo a whole stack of recent changes.

Of course I would be glad to do this again. Only - if you first like to debate 
wether the concept is desirable or not (I would have no problem with a 
discussion about), I would rather save my time for more usefull work and 
probably do the work after - if still necessray.

>OK. I still don't like the name :-). I would go for something like
>TaskContainer. Not a bug deal

No problem, I could change this.

>You shouldn't be checking for non-exceptional cases in
>the catch block, IMHO. Why not move this into the try block and handle it
>there. Perhaps, a change in introspectionHelper would be needed to make that
>work cleanly. In the end you are assuming that the cause of the build
>exception is due to the inability to create a nested element, and that is
>not a good thing.

Well I completly agree. The reason was not to change too much of existing code 
and confuse too much people. Personaly I am rather a Person of doing it good 
and right and not only working.

>It is an interesting question about who should be responsible for firing the
>task started and task finished events. Should it be the task or the
>container. I actually don't have a strong opinion either way.

Handlers (Listeners) may depend on the correct order during task execution. 
Therefor I decided to pack it all together and make shure the order (lik a 
protocoll) is allways strict.

View raw message