RE: macrodef attributes as properties or as textual substitutions [was local]
Sorry to have taken so long for me to answer this message but I am
quite busy at work and haven't had the time.
I would like to give some of my perspective on the issue of
macrodef/ and local/.
My first comment is that I really believe these two features should
be kept apart. I do not think macrodef/ should use local
in the implementation of atribute. I am in the camp of macrodef
doing a textual expansions (and here I would relent my objections to
a different syntax for attribute variables, in exchange for having
textual replacement done right).
By textual replacement done right, I mean that the scope of the textual
replacement is static on the text of the macro at the time of
definition.
That is the replacement should not apply to the value of attributes or
elements passed in the call. So in the famous example:
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=$(a)/echo
echo name=b value=$(b)/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
The output will still be:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
More over, the following call (see usage of attribute notation):
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=$(work) b=$(play) /
/precompile
/outer
/target
Will also output:
test.outer:
[echo] name=a value=$(work)
[echo] name=b value=$(play)
Because the substitutions of $(work)/$(play) attributes MUST occur
before the expansion of precompile/.
Why am I so adamant about it? Because I believe a user of a macro
should be isolated from the implementation of the task sa macro. I
should
be able to reimplement a macrodef as a java task and maintain
complete compatibility. This means that macros, like tasks, must
set properties or references to pass information between them.
I shouldn't be able to do with a macro something that cannot be done
cleanly with a task.
Now, with respect to local. The way I originally envisioned local
was very similar params of ant. They redefine (overide) the value
of a property for a well defined period of time (the local nesting)
and after that the property reverts to its original value (state).
Very simple. Since then there has been added functionality for
multithreading
which I think has made local a little too complex for my taste.
I think we should try to simplify this feature so it touches core the
least possible. Today I think the implementation touches a lot of places
of core, that should be reduced to just a few (making local a subtask
of sequential would help on some of that simplification).
Will stop here now I here your comments,
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 03 November 2003 14:08
To: [EMAIL PROTECTED]
Subject: Re: macrodef attributes as properties or as
textual substitutions [was local]
On Fri, 31 Oct 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
What are the advantages of leaving macrodef with attributes
implemented as textual substitutions ?
attributes don't hide properties.
If we implement attributes as properties, we have to decide
whether they are allowed to override existing
(user-)properties of the same name as well. I don't think it
would be problematic, as long as we state the rules clear enough.
If they are only textual substitutions, they get confusing
when we use the property expansion syntax.
Otherwise, of course, if we leave macrodef as it is with just a new
notation for the attributes, then we can release 1.6 sooner.
I'd rather get this right as in community supported and
unlikely to break bc in Ant 1.7 now.
If we choose a notation $() for macro attributes (for
instance), can
we implement macrodef with local/ in 1.7 ?
You mean we make them textual replacements now and set
(local) properties in 1.7? This would imply that attributes
that didn't hide properties in 1.6 would do so now. And
should we decide that attributes must not override existing
properties, this suddenly would have to apply to $() instead
of ${} as well.
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]
RE: macrodef attributes as properties or as textual substitutions [was local]
This makes a lot of sense to me, especially given your willingness to
consider a different notation (very important, IMHO). To me, a macro IS
a textual substitution, and anything that leaves things in an undefined
or difficult-to-explain middle state is asking for trouble. They're
different sorts of beasts and this should not be muddied.
Steve Cohen
Sr. Software Engineer
Sportvision, Inc.
scohenATSportvisionDOTcom
-Original Message-
From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 10:30 AM
To: Ant Developers List
Subject: RE: macrodef attributes as properties or as textual
substitutions [was local]
Sorry to have taken so long for me to answer this message but I am
quite busy at work and haven't had the time.
I would like to give some of my perspective on the issue of macrodef/
and local/.
My first comment is that I really believe these two features should be
kept apart. I do not think macrodef/ should use local in the
implementation of atribute. I am in the camp of macrodef doing a
textual expansions (and here I would relent my objections to
a different syntax for attribute variables, in exchange for having
textual replacement done right).
By textual replacement done right, I mean that the scope of the textual
replacement is static on the text of the macro at the time of
definition. That is the replacement should not apply to the value of
attributes or elements passed in the call. So in the famous example:
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=$(a)/echo
echo name=b value=$(b)/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
The output will still be:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
More over, the following call (see usage of attribute notation):
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=$(work) b=$(play) /
/precompile
/outer
/target
Will also output:
test.outer:
[echo] name=a value=$(work)
[echo] name=b value=$(play)
Because the substitutions of $(work)/$(play) attributes MUST occur
before the expansion of precompile/.
Why am I so adamant about it? Because I believe a user of a macro should
be isolated from the implementation of the task sa macro. I should be
able to reimplement a macrodef as a java task and maintain complete
compatibility. This means that macros, like tasks, must set properties
or references to pass information between them. I shouldn't be able to
do with a macro something that cannot be done cleanly with a task.
Now, with respect to local. The way I originally envisioned local
was very similar params of ant. They redefine (overide) the value of
a property for a well defined period of time (the local nesting) and
after that the property reverts to its original value (state). Very
simple. Since then there has been added functionality for multithreading
which I think has made local a little too complex for my taste.
I think we should try to simplify this feature so it touches core the
least possible. Today I think the implementation touches a lot of places
of core, that should be reduced to just a few (making local a subtask
of sequential would help on some of that simplification).
Will stop here now I here your comments,
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 03 November 2003 14:08
To: [EMAIL PROTECTED]
Subject: Re: macrodef attributes as properties or as
textual substitutions [was local]
On Fri, 31 Oct 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
What are the advantages of leaving macrodef with attributes
implemented as textual substitutions ?
attributes don't hide properties.
If we implement attributes as properties, we have to decide
whether they are allowed to override existing
(user-)properties of the same name as well. I don't think it
would be problematic, as long as we state the rules clear enough.
If they are only textual substitutions, they get confusing
when we use the property expansion syntax.
Otherwise, of course, if we leave macrodef as it is with just a new
notation for the attributes, then we can release 1.6 sooner.
I'd rather get this right as in community supported and
unlikely to break bc in Ant 1.7 now.
If we choose a notation $() for macro attributes (for
instance), can
we implement macrodef with local/ in 1.7 ?
You mean we make them textual
Re: macrodef attributes as properties or as textual substitutions [was local]
My view is that we should use (local) properties for macrodef attributes.
Doing this corresponds more closely to current usage of antcall/ for
templates.
If however, one uses textual substitutions, I agree that one
should use a different syntax/notation for the attributes.
$(x) may however be too similar to ${x}
As regards local/. I think that the local properties should be
thread local. I.e. the following should not cause grief.
parallel
sequential
local name=x value=1/
echox is ${x}/echo
/sequential
sequential
local name=x value=2/
echox is ${x}/echo
/sequential
/parallel
Peter
On Wednesday 05 November 2003 16:30, Jose Alberto Fernandez wrote:
Sorry to have taken so long for me to answer this message but I am
quite busy at work and haven't had the time.
I would like to give some of my perspective on the issue of
macrodef/ and local/.
My first comment is that I really believe these two features should
be kept apart. I do not think macrodef/ should use local
in the implementation of atribute. I am in the camp of macrodef
doing a textual expansions (and here I would relent my objections to
a different syntax for attribute variables, in exchange for having
textual replacement done right).
By textual replacement done right, I mean that the scope of the textual
replacement is static on the text of the macro at the time of
definition.
That is the replacement should not apply to the value of attributes or
elements passed in the call. So in the famous example:
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=$(a)/echo
echo name=b value=$(b)/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
The output will still be:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
More over, the following call (see usage of attribute notation):
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=$(work) b=$(play) /
/precompile
/outer
/target
Will also output:
test.outer:
[echo] name=a value=$(work)
[echo] name=b value=$(play)
Because the substitutions of $(work)/$(play) attributes MUST occur
before the expansion of precompile/.
Why am I so adamant about it? Because I believe a user of a macro
should be isolated from the implementation of the task sa macro. I
should
be able to reimplement a macrodef as a java task and maintain
complete compatibility. This means that macros, like tasks, must
set properties or references to pass information between them.
I shouldn't be able to do with a macro something that cannot be done
cleanly with a task.
Now, with respect to local. The way I originally envisioned local
was very similar params of ant. They redefine (overide) the value
of a property for a well defined period of time (the local nesting)
and after that the property reverts to its original value (state).
Very simple. Since then there has been added functionality for
multithreading
which I think has made local a little too complex for my taste.
I think we should try to simplify this feature so it touches core the
least possible. Today I think the implementation touches a lot of places
of core, that should be reduced to just a few (making local a subtask
of sequential would help on some of that simplification).
Will stop here now I here your comments,
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 03 November 2003 14:08
To: [EMAIL PROTECTED]
Subject: Re: macrodef attributes as properties or as
textual substitutions [was local]
On Fri, 31 Oct 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
What are the advantages of leaving macrodef with attributes
implemented as textual substitutions ?
attributes don't hide properties.
If we implement attributes as properties, we have to decide
whether they are allowed to override existing
(user-)properties of the same name as well. I don't think it
would be problematic, as long as we state the rules clear enough.
If they are only textual substitutions, they get confusing
when we use the property expansion syntax.
Otherwise, of course, if we leave macrodef as it is with just a new
notation for the attributes, then we can release 1.6 sooner.
I'd rather get this right as in community supported and
unlikely to break bc in Ant 1.7 now.
If we choose a notation $()
RE: macrodef attributes as properties or as textual substitutions [was local]
Doing this corresponds more closely to current usage of antcall/ for
templates.
Yes, but I think this may not be such a good thing. I have, as I
recall, oftentimes been tripped up on the question of when a variable is
defined. I know java has no preprocessor, but it doesn't have macros
either. If we are going to introduce macros in ant, I think that the
clarity of knowing that they are defined at load time, and not at
runtime is an advantage. antcall
has never been a good way to do templates.
Although I might be open to a convincing counter-example.
Steve Cohen
Sr. Software Engineer
Sportvision, Inc.
scohenATSportvisionDOTcom
-Original Message-
From: peter reilly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, November 05, 2003 11:38 AM
To: Ant Developers List
Subject: Re: macrodef attributes as properties or as textual
substitutions [was local]
My view is that we should use (local) properties for macrodef
attributes. Doing this corresponds more closely to current usage of
antcall/ for templates.
If however, one uses textual substitutions, I agree that one should use
a different syntax/notation for the attributes.
$(x) may however be too similar to ${x}
As regards local/. I think that the local properties should be thread
local. I.e. the following should not cause grief.
parallel
sequential
local name=x value=1/
echox is ${x}/echo
/sequential
sequential
local name=x value=2/
echox is ${x}/echo
/sequential
/parallel
Peter
On Wednesday 05 November 2003 16:30, Jose Alberto Fernandez wrote:
Sorry to have taken so long for me to answer this message but I am
quite busy at work and haven't had the time.
I would like to give some of my perspective on the issue of
macrodef/ and local/.
My first comment is that I really believe these two features should be
kept apart. I do not think macrodef/ should use local in the
implementation of atribute. I am in the camp of macrodef doing a
textual expansions (and here I would relent my objections to a
different syntax for attribute variables, in exchange for having
textual replacement done right).
By textual replacement done right, I mean that the scope of the
textual replacement is static on the text of the macro at the time of
definition. That is the replacement should not apply to the value of
attributes or
elements passed in the call. So in the famous example:
macrodef name=inner
attribute name=a/
attribute name=b/
sequential
echo name=a value=$(a)/echo
echo name=b value=$(b)/echo
/sequential
/macrodef
macrodef name=outer
attribute name=work/
attribute name=play/
element name=precompile optional=true/
element name=additional optional=true/
sequential
precompile/
additional/
/sequential
/macrodef
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=${work} b=${play} /
/precompile
/outer
/target
The output will still be:
test.outer:
[echo] name=a value=${work}
[echo] name=b value=${play}
More over, the following call (see usage of attribute notation):
target name=test.outer
outer work=this is work play=this is play
precompile
inner a=$(work) b=$(play) /
/precompile
/outer
/target
Will also output:
test.outer:
[echo] name=a value=$(work)
[echo] name=b value=$(play)
Because the substitutions of $(work)/$(play) attributes MUST occur
before the expansion of precompile/.
Why am I so adamant about it? Because I believe a user of a macro
should be isolated from the implementation of the task sa macro. I
should be able to reimplement a macrodef as a java task and
maintain complete compatibility. This means that macros, like tasks,
must set properties or references to pass information between them.
I shouldn't be able to do with a macro something that cannot be done
cleanly with a task.
Now, with respect to local. The way I originally envisioned local
was very similar params of ant. They redefine (overide) the value
of a property for a well defined period of time (the local nesting)
and after that the property reverts to its original value (state).
Very simple. Since then there has been added functionality for
multithreading which I think has made local a little too complex for
my taste.
I think we should try to simplify this feature so it touches core the
least possible. Today I think the implementation touches a lot of
places of core, that should be reduced to just a few (making local a
subtask of sequential would help on some of that simplification).
Will stop here now I here your comments,
Jose Alberto
-Original Message-
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
Sent: 03 November 2003 14:08
To: [EMAIL PROTECTED]
Subject: Re: macrodef attributes as
Re: macrodef attributes as properties or as textual substitutions [was local]
On Fri, 31 Oct 2003, Antoine Levy-Lambert [EMAIL PROTECTED]
wrote:
What are the advantages of leaving macrodef with attributes
implemented as textual substitutions ?
attributes don't hide properties.
If we implement attributes as properties, we have to decide whether
they are allowed to override existing (user-)properties of the same
name as well. I don't think it would be problematic, as long as we
state the rules clear enough.
If they are only textual substitutions, they get confusing when we use
the property expansion syntax.
Otherwise, of course, if we leave macrodef as it is with just a new
notation for the attributes, then we can release 1.6 sooner.
I'd rather get this right as in community supported and unlikely to
break bc in Ant 1.7 now.
If we choose a notation $() for macro attributes (for instance), can
we implement macrodef with local/ in 1.7 ?
You mean we make them textual replacements now and set (local)
properties in 1.7? This would imply that attributes that didn't hide
properties in 1.6 would do so now. And should we decide that
attributes must not override existing properties, this suddenly would
have to apply to $() instead of ${} as well.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
macrodef attributes as properties or as textual substitutions [was local]
Here is a new subject. What are the advantages of leaving macrodef with attributes implemented as textual substitutions ? My impression is that the local properties are more powerful. Otherwise, of course, if we leave macrodef as it is with just a new notation for the attributes, then we can release 1.6 sooner. If we choose a notation $() for macro attributes (for instance), can we implement macrodef with local/ in 1.7 ? or will we have a problem of backward compatibility in any case ? Cheers, Antoine -Ursprungliche Nachricht- Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 31. Oktober 2003 17:13 An: [EMAIL PROTECTED] Betreff: Re: local On Fri, 31 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: On Friday 31 October 2003 15:55, Stefan Bodewig wrote: On Fri, 31 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: No, it matters if the attributes in macrodef are implemented as properties or if they are implemented as textual subsitutions. OK, but then this becomes the question to decide and not whether we need local in 1.6, right? Yes Do we need a different thread to get a wider audience? If they are properties, we don't need an alternative. What are the difficulties you expect when they are not properties? Only the choice of the notation. MSBuild uses $() for its properties and @() for something else - probably Item references at first glance. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef attributes as properties or as textual substitutions [was local]
From my point of view, I am sitting with a massive, slow, and messy build script that I would love to convert to using macrodefs instead of antcalls. I am waiting for this to be resolved before proceeding. On the other hand, I can live with what I have for awhile. Some preliminary experiences have indicated problems which I shared with the dev list earlier this week. I imagine that whatever scheme is chosen will require some sizable effort to convert. I would rather not do this in 1.6 and then again in 1.7, unless the conversion path is easy. What I don't understand in Antoine's question is whether the new notation would have to be scrapped for the new implementation of local in 1.7 or whether it would still apply. Unless this is going to delay the release for months, I would say, get it right, now. Steve Cohen Sr. Software Engineer Sportvision, Inc. scohenATSportvisionDOTcom -Original Message- From: Antoine Levy-Lambert [mailto:[EMAIL PROTECTED] Sent: Friday, October 31, 2003 10:31 AM To: Ant Developers List Subject: macrodef attributes as properties or as textual substitutions [was local] Here is a new subject. What are the advantages of leaving macrodef with attributes implemented as textual substitutions ? My impression is that the local properties are more powerful. Otherwise, of course, if we leave macrodef as it is with just a new notation for the attributes, then we can release 1.6 sooner. If we choose a notation $() for macro attributes (for instance), can we implement macrodef with local/ in 1.7 ? or will we have a problem of backward compatibility in any case ? Cheers, Antoine -Ursprungliche Nachricht- Von: Stefan Bodewig [mailto:[EMAIL PROTECTED] Gesendet: Freitag, 31. Oktober 2003 17:13 An: [EMAIL PROTECTED] Betreff: Re: local On Fri, 31 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: On Friday 31 October 2003 15:55, Stefan Bodewig wrote: On Fri, 31 Oct 2003, peter reilly [EMAIL PROTECTED] wrote: No, it matters if the attributes in macrodef are implemented as properties or if they are implemented as textual subsitutions. OK, but then this becomes the question to decide and not whether we need local in 1.6, right? Yes Do we need a different thread to get a wider audience? If they are properties, we don't need an alternative. What are the difficulties you expect when they are not properties? Only the choice of the notation. MSBuild uses $() for its properties and @() for something else - probably Item references at first glance. - 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]
RE: macrodef attributes as properties or as textual substitutions [was local]
--- Steve Cohen [EMAIL PROTECTED] wrote: From my point of view, I am sitting with a massive, slow, and messy build script that I would love to convert to using macrodefs instead of antcalls. I am waiting for this to be resolved before proceeding. On ... Unless this is going to delay the release for months, I would say, get it right, now. +1 -Matt __ Do you Yahoo!? Exclusive Video Premiere - Britney Spears http://launch.yahoo.com/promos/britneyspears/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
