@{x}because it looks like "put the substitution AT this location" when I read it to myself.
However I can understand that $ escaping is already done and well tested so reusing that code has value. $(x) is good enough for me if that is a priorety (you will note I am not offering to code @{x} :) ).
(or we could make it (:x:) so that mozilla can turn them all into smilies when we paste it to the list :) )
-Gus
Stefan Bodewig wrote:
On Mon, 17 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
OK, how do we want to implement <macrodef> attributes: current [ ] as textual substitution ~ 4 [ ] as "real" Ant properties ~ 2
undecided ~ 1
only counting the "binding" votes would result in 1/2/1, so neither choice has received enough binding votes by now. Dominique, Jose Alberto and Steve know that I'm not ignoring their votes, but technically they are non-binding.
If macrodef attribute are to be implements as substitutions, what should be the notation? (where x is the attribute name)
[ ] as ${x} (look like ant properties)
-1, too confusing.
[ ] as @x
-1 doesn't work if you want to concatenate an expanded attribute and some other text, i.e.
<attribute name="foo"/> <attribute name="foobar"/>
is @foobarbaz the expansion of foo plus the literal text barbaz or is it the attribute foobar plus the literal text baz - or something completely different?
[ ] as ${attribute:x}
-1 - still looks too much like a property and collides with existing properties that's name starts with "attribute:" (unlikely but possible).
[ ] as $(x) [ ] as @{x}
either one works for me - as well as [EMAIL PROTECTED]
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]
