Costin Manolache wrote:
Dominique Devienne wrote:
As I've been saying all along, lets just introduce a new (unique) notion
for attribute/variable expansion (at use time rather than definition
time), which
is something new in Ant anyhow. No (or less?) backward compatibility
issues, and makes it plain and obvious what is what:
${name} it's a property!
(@name) it's an attribute/variable!!!
I think this is a bad idea.
Chosing between macrodef and ant simplicity - I preffer the second.
There are already a lot of complex rules in <ant> and <antcall> and
<import>, I think the last thing we need is a new syntax for "macrodef
variables".
Costin
Is it simpler to add yet another complex rule to the meaning of ${foo}
or to attach the new rule to a new syntax that only needs to be learned
for the use of macrodef only. Anyone who hasn't used macrodef will see
the new syntax in a build and know there is something different going on
with (@foo) (or whatever). By contrast, ${foo} will appear to be
something the user has seen before, but produce unexpected behaviors...
and perhaps bug reports? Furthermore, if the syntax is the same, then
one needs both scoping/rules to identify the type of ${} and rules about
it's behavior. If the syntax is different there is no need to
distinguish it because it is already distinct. One could make all their
replace tokens look like properties too, but I suspect this is not a
common thing to do for the similar reasons.
No context, no unnecessary brain cycles to figure out what is what.
I'll be just as glad as the next guy to use <macrodef>, I just don't want
that
power to come of the expanse of Ant's simplicitly and user-friendliness.
---------------------------------------------------------------------
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]
