ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: Getting 1.6 out the door
Date Mon, 01 Sep 2003 18:10:41 GMT
On Monday 01 September 2003 16:43, Dominique Devienne wrote:
> > -----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.

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/config[@id='(@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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message