ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <>
Subject Re: My itches with <local> (was Re: [VOTE] local for 1.6)
Date Wed, 19 Nov 2003 10:58:07 GMT
On Wednesday 19 November 2003 09:46, Stefan Bodewig wrote:
> On Tue, 18 Nov 2003, peter reilly <> wrote:
> > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> >> 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
> >
> > I think that this looks clumsy.
> possible - I'm not afraid of looking clumsy 8-)  This is IMHO a case
> where verbosity is a win.
> > (note as well that local-property is not a valid name,
> Why not?  Nothing's going to stop my from taskdeffing that name and
> <local> is a TaskContainer.

Correct, I just assumed that as local-property element only made sense in
your example as an nested element of the <local> and hense was a result of
an add/create<Name>() introspection method.

> Anyway, I'm in no way attached to any
> name, I would even be fine with <let> as the name of the container,
> but I'm afraid that not too many users would recognize this.

Or worst, too many users may recognize it...

> >> (2) Shadowing of 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.
> Maybe.  It would be enough to isolate macrodef invocations from each
> other, though.
> Allowing them to override "plain" properties opens up the "properties
> are immutable" rule and makes it a "properties are immutable unless
> overridden in a <local>".

It does not (in my opinion) do this anymore that using <antcall>
with <param> nested elements.

<target name="docall">
  <property name="x" value="global"/>
  <antcall target="othertarget">
     <param name="x" value="different value than '${x}'"/>

> This even stronger asking for a
> TaskContainer IMHO.
> What is your usecase for overriding properties?

Mysterious failures of macro's because some build file's use
a particular property name and others do not.

Normally people use short names for local variables - file, text etc.
They could be used at the different scopes.

Also recursive macrodefs would have a problem:
<macrodef name="recur">
  <attribute name="number"/>
       <echo>number is @{number}</echo>
       <localproperty name="mynumber"/>
            datatype  = "int"
            result    = "mynumber"
            operand1  = "@{number}"
            operation = "-"
            operand2  = "1"
          <ac:equals arg1="0" arg2="${mynumber}"/>
              <recur number="${mynumber}"/>

(ok, maybe "localpropertycontainer" is a bit much)

> > The idea of not overridding user properties comes from the <ant>
> > family behaviour,
> Not only.  Even setProperty will not override a use property.

Ok, the idea actually came for your previous e-mail pointing this out ....


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

View raw message