ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antoine Lévy-Lambert <anto...@antbuild.com>
Subject AW: <local>
Date Fri, 31 Oct 2003 12:40:57 GMT
Do I understand right that the "dynamic extent" is the behavior of
properties nested into an antcall invocation ?

In this case, I think that the attributes of macrodef should also have this
behavior.

If the attributes of macrodef are implemented as <local/> properties, then
these properties should have this "dynamic extent behavior".

Thoughts ?

Antoine

-----Urspr√ľngliche Nachricht-----
Von: peter reilly [mailto:peter.reilly@corvil.com]
Gesendet: Freitag, 31. Oktober 2003 11:08
An: Ant Developers List; Stefan Bodewig
Betreff: Re: <local>


On Friday 31 October 2003 09:37, Stefan Bodewig wrote:
> On Fri, 31 Oct 2003, peter reilly <peter.reilly@corvil.com> wrote:
> > On Friday 31 October 2003 08:49, you wrote:
>
> "you" being Antoine 8-)
>
> >> I do not understand fully what you mean by static scoping. Can you
> >> explain this dilemma static scoping/dynamic extend on the mailing
> >> list ?
>
> Take Java which uses static extent (like most languages we are used of)
>
> int i = 1;
> void method() {
>     System.err.println(i);
> }
>
> void method2() {
>     int i = 2;
>     method();
> }
>
> If you run method2(), method() will not see the local value of i which
> "shadows" the global i.
>
> Dynamic extent on the other side would make method() see the local
> value of i.  Emacs Lisp does so, as do (only some?) other Lisp
> dialects.
>
> Moving to Ant and <local>, the question is whether builds invoked via
> <ant> should see the local definition or the global definition of a
> property.  In particular, whether the property was set in the child
> build when there is no global property at all.  Peter, Jose Alberto
> and I came to the conclusion that <ant> and <macrodef> should be
> treated the same way.
>
> Both static and dynamic extent have their pros and cons - and after
> thinking it over again I'm more leaning to the dynamic side right now,
> but can certainly make up my mind once again 8-)

It is probally cleaner/more consistent to make them dynamic, but
it is probally more confusing as well. I am agnostic on this.

>
> >> > Maybe people (including me) are more concerned with the possible
> >> > delay in releasing ant 1.6 than with the matter itself. Stefan
> >> > for instance sent an email last week where he wrote he was
> >> > concerned about release date.
>
> Uhm, not exactly.
>
> I was under the impression that the discussion led to an end where
> <macrodef> wasn't affected - no matter whether we introduced <local>
> or not.  In this case I'd say that <local> should not hold up the
> release.

No, it matters if the attributes in macrodef are implemented as properties
or if they are implemented as textual subsitutions.

If they are textual substituations, the local properties will not work too
good. To take Jose's syntax for local -

<macrodef name="m">
   <attribute name="x"/>
   <sequential>
      <local name="x" value="a local property">
          <echo>this is ${x}</echo>
      </local>
   </sequential>
</macrodef>

In this case, I think that Dominique's critik of ${} for textual
attribute substitution is correct. However any alternative notation
has difficulities.

Peter
>
> There are issues with <macrodef> as it is as well as with the usage of
> the default namespace on nested elements.  I think we better get both
> things right before we release 1.6, no matter how long it takes.
>
> Stefan
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message