Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: ant-dev@jakarta.apache.org
To: ant-dev@jakarta.apache.org
Subject: Re: executing task for each file in file set
References: <011101c0f58d$a763e6f0$da76883e@viquity.com>
From: Stefan Bodewig <bodewig@apache.org>
Date: 18 Jun 2001 11:30:18 +0200
Message-ID: <m34rtexhhx.fsf@bodewig.bost.de>
Lines: 113
User-Agent: Gnus/5.0807 (Gnus v5.8.7) XEmacs/21.1 (Cuyahoga Valley)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii

Jose Alberto Fernandez <j_a_fernandez@yahoo.com> wrote:

> Let me first say that I am open here. I am just trying to get a
> discussion going and trying to teased people into thinking whether
> we need this at all and if we do how it should look like.

Sure, seems as if it didn't work though 8-(

>> At some point during discussion about Ant2 we've more or less
>> agreed that there'll be an antcall version that doesn't use an
>> execution context of its own - so that would cover (a) as well.
> 
> Did we agreed to that? I thought we were talking about nested
> <tasks>, but not about some other <antcall> behaviour.

Maybe my memory is failing as I cannot find it in the list of accepted
features either.

> It is up to us, to define the feature in such a way to minimize
> future "problems". Worst that parallel access, it is parallel
> modification of the execution environment. If the construct allows
> that, then it will be very difficult to achieve parallelism or some
> other execution paradigm we may think of in the future.

We will have to deal with this problem in the context of
multi-threaded execution of tasks in a target anyway.  This probably
means that bigger parts of the core need to be redesigned for
multi-threading and that we document side-effects of some tasks
properly (so people know when they are going to get themselves into
trouble).

> What happens if "iteration property name" has been defined before?

Say we wouldn't permit that?

> Can the task(s) inside the construct define properties visible at
> the end?  e.g., doing an <available> loop? What do we do if they
> apply to the same property name?

What do we do if people put several available tasks for the same
property name into a section where tasks will be run in parallel?  The
problem is not specific to a apply-to-set construct.

Currently I'd say that people should know they are getting into
trouble with this - and be held responsible for it themselves.

> Sure, the "set" interface does not necessarily need to be visible to
> users.  Although, it may be difficult to explain what kind of
> "types" can be used in an <union> if we do not have some unifying
> concept. So it seems it will have to show up at least as a
> documentation concept.

Yes.

>> > Question 3) What should be the syntax?
>>
>> Depends a lot upon the answer to Question 1).
>>
>> You are going quite a long way to avoid task-scoped properties,
>> aren't you?
> 
> Hey, I am trying to start a row (I mean a discussion :-) ).

Did I forget a smiley? Don't think I'll always need one ;-)

> Yeap, nested constructs are powerful. But if we go that way, what
> stops us from having the same argument about <if><else> (or maybe
> <choice><case></choice>) type of constructs?

Who said we wouldn't have these arguments?  

We are going to allow container tasks anyway - we need them for the
multi-thread implementation like we've currently planned it.  I'm sure
somebody will create choice/switch/select/if/whatever tasks based on
this construct - and I think this is OK.  If you feel you need an if
task, the container task way lends itself to it.

> How about all the arguments about "if" at task level? Whouldn't
> these constructs be doing exactly the same?

Sure.

> Do we still believe they are bad, while <applyto> is more
> acceptable?

More acceptable in a sense that it could be part of the core tasks
while the others could not?  I'm not sure, really.  Let's say that
following ant-user over the last weeks (ever since Tim has submitted
his foreach task and Diane has started pointing people to it) has
changed my mind quite a bit.  Usually I've asked people to explain
what they are trying to do and searched for an alternative that
wouldn't ask for these constructs - I still haven't seen an if or case
example that has convinced me, while I've seen quite a few problems
that could be solved by the foreach task (and I didn't know a better
solution).

> In ANT we have come up with a pattern for calling a subroutine which
> is based on <antcall> and the definition of <target>s.

Have we?

[targets as methods]

> Should we have it, should we not? What should be the principle
> behind our answer?

Well, to dogmatically answer the first. No! Just see the vote for Ant2
features, it has been vetoed by no less that five committers.

I don't have a less dogmatic answer at this time - I need to get some
things sorted out before I can come up with one.

Stefan