ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: Getting 1.6 out the door
Date Mon, 01 Sep 2003 15:43:01 GMT
> -----Original Message-----
> From: peter reilly [mailto:peter.reilly@corvil.com]
> >
> > 3. <macrodef> and <presetdef>
> >
>   a) resolution of properties
>      The issue here is that properties get resolved when the 
>      macro is used and not when the macro is defined.
>      I think that it would be difficult to resolve the 
>      properties correctly when the macro is defined.
>
>      I think that the current implementation and behaviour is 
>      preferable.

I think it's sad that you reflect on this from the implementation
perspective rather than the user's one... One of the major 'feature'
of Ant is that it is very explicit and relatively simple.

It's not all about power, or one would use a real programming language
like Perl or Python. <macrodef>, although powerful, complexifies the rules
of Ant, namely the property expansion one, making it context dependent!

Never underestimate the power and simplicity of context/scope free rules.
Although Ant already has scopes with <ant>/<antcall>/<subant>, the property
expansion rules works the same everywhere, and I'd like this to stay the
same.

>   b) syntax of attributes
>      After using macrodef for a little while (well mostly in writing
>      examples), I think that ${name} feels the best.

That's one opinion. You obviously don't mind complexity yourself b-)
I, OTOH, prefer things clear&simple, with the least possible surprise.

>      In future I expect that there will be different scopes for
>      variables/properties (perhaps only for ant-contrib / antelope
>      / other and not in core ant), - task level variables, macro level
>      variables and global variables (properties). It would be strange
>      to  have different syntax for each.

Wowwww, hold on! We're not turning Ant into a programming language,
remember?

> 
>      However this (unlike a) is easy to code for :-), if ${name} syntax
>      is not liked my other preference would be ${macroattr:name}.

Sigh... Again, this notation would introduce a subtle variation on property
expansion, which may indeed be backward incompatible. It's currently
perfectly
OK to have regular property names that for some reason start with
macroattr:.

Property interceptors are not part of Ant, and might never be for that
matter.
Using a notation that mimicks interceptors is probably not a good idea
either.

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!!!

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.
--DD

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message