ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gus Heck <gus-ant...@cognition.olin.edu>
Subject Re: Getting 1.6 out the door
Date Wed, 03 Sep 2003 16:33:33 GMT
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: 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