On Monday 01 September 2003 16:43, Dominique Devienne wrote:
> > -----Original Message-----
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > > 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.
The problem is that I do not know how (or if it is possible) to implement the
feature of expanding the properties at definition time.
>
> 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.
<macrodef> follows (I think) the same rules of properties as <antcall> with
inheritall=yes.
<target name="do.echo.target">
<echo>${do.echo}</echo>
<do.echo.task/>
</target>
<target name="do.echo.test">
<macrodef name="do.echo.task">
<sequential>
<echo>${do.echo}</echo>
</sequential>
</macrodef>
<antcall target="do.echo.target">
<param name="do.echo" value="Hello world"/>
</antcall>
</target>
<macrodef> should make ant a little simpler by removing the need
for a lot of <antcall>s. People sometimes use them at the moment to emulate
macros/templates.
Normally (I think), <macrodef> would be used in the same project that defined
it, so the rules for property expansion would not be an issue.
>
> > 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.
Ok, after using perl, I do not like the idea of having different
syntax for different (but similar) things.
>
> > 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?
But it is one of the objectives/consequences of ant-contrib/antelope.
One would like to do things like:
<notation:warning name="Use of ant as a progamming language"
<foreach param="file">
<path>
<fileset dir="${test.dir}/mains" includes="*.cpp"/>
<pathelement
path="${test.dir}/probeoffline/probeoffline.cpp"/>
<pathelement path="src/shell/probesh.cpp"/>
</path>
<sequential>
<propertyregex
property="program" input="${file}"
regexp=".*/([^\.]*)\.cpp" replace="\1"/>
<compile-exec program="${program}">
<cc-files>
<path path="${file}"/>
</cc-files>
</compile-exec>
<compile-exec-file file="${file}"/>
</sequential>
</foreach>
</notation:warning>
without the "program" property being visible outside the foreach
sequential element.
>
> > 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:.
Ok, scratch ${macroattr:name}.
>
> 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!!!
yes but (IMO) this is confusingly similar to XPath use of variables.
<macrodef name="cut">
<attribute name="use">
<sequential>
<xmltask source="input.xml" dest="1.xml >
<cut path="web/servlet/context/[EMAIL PROTECTED]'(@use)']"
buffer="storedXml" />
</xmltask>
</sequential>
</macrodef>
>
> 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.
+1
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
