ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: My itches with <local> (was Re: [VOTE] local for 1.6)
Date Tue, 18 Nov 2003 17:05:53 GMT
> From: peter reilly [] 
> On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> >
> > Things we need to consider IMHO:
> >
> > (1) Syntax
> >
> > Your proposal uses a <local> task that sets up a local scope for a 
> > named property until the enclosing target/sequential 
> finishes.  Jose 
> > Alberto suggested to use a <local> TaskContainer instead, something 
> > like
> >
> > <local>
> >   <local-property name="...."/>
> > </local>
> >

Just for the record, my syntax was more like:

<local property="...." [value="...."]>

Which does not need inner special elements (less clumsy) but it
requires one nesting per property (but really, how many locals
would you have one after the other?)

> > which would essentially just add an explicit (and 
> differently named) 
> > <seqential> to your proposal.  I think I prefer the more explicit, 
> > even if more verbose syntax of the second form.
> I think that this looks clumsy. Making local's valid for the 
> current block scope (target level, or sequential level) feels (to
> me) more natural. However, I can see benefits ;- my code may 
> not catch all uses of sequential.

My major issue with the current implementation proposal is that
it touches way too many places in the code. It needs to change the
implemention of almost all the usages of sequential (and target).
In my design it should only touch <local> itself and the datastructures
for property handling (given that we want to use threadlocals).

It is a very much less footprint and that I think is good.

> (note as well that local-property is not a valid name, 
> localproperty would be correct).
> > (2) Shadowing of properties
> >
> > Your updated proposal ensures that local properties do not override 
> > "global" user properties.  I think they shouldn't be allowed to 
> > override any outer scope properties at all.
> I think that this will reduce their usefullness a lot. The 
> idea of not overridding user properties comes from the <ant> 
> family behaviour, but they can overriden other properties.

Agreed, if I cannot override properties, what was the point of all this
The proposal always allowed to override properties.

> >
> > (3) Extent of local properties
> >
> > You make the local properties available to <script> - will 
> they also 
> > be available for builds that get called with the <ant> 
> family of tasks 
> > (assuming inheritall is true)?  I think they should be.
> Yes this is implemented.

Can we make sure that all the tasks that are based on <ant>
will automagically get this done right? This I think is my major
fear in all this, that 3rd party <foreach> and co. will not work

Jose Alberto

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

View raw message