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:[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
