ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <>
Subject RE: [new tasks] presetdef and macrodef
Date Thu, 14 Aug 2003 16:44:03 GMT
> -----Original Message-----
> From: peter reilly []
> Sent: Thursday, August 14, 2003 11:22 AM
> To: Ant Developers List
> Subject: Re: [new tasks] presetdef and macrodef
> It is not a sub-set of <macrodef/>. But there is a lot of overlap of
> functionality. In fact after I got embeded elements to work for
> <macrodef/>,
> I replaced most uses of <presetdef/> with <macrodef/>.
> I think however that there is a place for <presetdef/> For example
> if you look at the current code of TaskDef, all it consists of is
> setting two properties. This can be expressed using <presetdef/> as
> <presetdef name="taskdef">
> 	<typedef adaptor=""
>                       adaptto=""/>
> </presetdef>
> When (if) roles are introducted, one implementation would be
> to add a "role" or "restrict" attribute to <typedef>.
>   <typedef name="or"
>         classname=""
>         restrict=""/>
>   <typedef name="or"
>         classname=""
>         restrict=""/>
> one could use <presetdef/> as
>    <presetdef name="conditiondef">
>        <typedef
>            restrict=""/>
>     </presetdef>
> and define:
>     <conditiondef name="or"
>            classname=""/>

OK, I clearly misunderstood <presetdef>... But then, you can also write:

<macrodef name="conditiondef">
  <typedef restrict=""/>

and still do, 

<conditiondef name="or"

Can't you? So what's exactly the difference between <presetdef> and
<macrodef>??? I still don't get it I'm afraid...

> > A middle ground would be to have something like this, closer to your
> > current design:
> >
> >   <bind-attributes>
> >     <delete quiet="true" />
> >     <javac debug="${debug}" deprecation="${deprecation}" />
> >     <exec failonerror="true" />
> >   </bind-attributes>
> >
> > So it yields no task rename, work for any valid tasks, and is more
> > explicit.
> True but not easy to implement (I think, although.....) and does
> something different to <presetdef/>.

I thought it was the goal of <presetdef>, but I was wrong of course.

> > > <macrodef>
> > >       </compile-exec>
> >
> > <macrodef> I have much less problem with, but I concur with others that
> > overloading the behavior of ${name} is not good. This will be confusing
> > to me and other users that property expansion will not happen as usual
> > at definition time, but later on.
> All of the expansions happen later on.  If the macro is used in a
> different project to the project it is defined in, the properties
> in use will be of the project that the macro is used in*.

Which is exactly why I don't like using the same syntax, which until now
*always* expanded as if at the place of definition/use!!!

> However, I can see
> that there can be issues with using the same notation for the macro
> expansion of attributes and then normal expansion of properties.

So we're you planning on refusing 'normal' property expansion in <macrodef>?
If two different syntax are used, it's obvious what's what.

> I am loath however to adding new rules for indicating variables.
> However if ant people want a different encoded for the macro variables,
> I would have no objection.

OK, let's see:
1) Introduce a new syntax (@name) for a new feature,
   thus keeping the existing syntax ${name} its only behavior
2) Overloading the existing ${name} syntax to behave differently
   in <macrodef>

It's a no brainer to me. I clearly vote for (1).

> > Another advantage of the second form is that one would not need to
> > pre-declare the macro params (making it scripting-language-like), but on
> > the other hand, pre-declaring makes it more explicitly when reading the
> > macro what parameters it takes. If we force pre-declaration, we can then
> > fail on dereference to non-declared macro-param.
> Yes, The current code does these checks.

So how do you distinguish between regular properties dereference and
<macrodef> attribute dereference again?

> > Should param be renamed attribute? <macrodef>, from the build writer
> > point of view, creates a new tasks, and we always speak of attributes
> > and nested elements, not params and nesting elements.
> I picked param, as some other tasks use param (foreach*,
> antcall) for something similar.

No, it's not something similar IMHO! You are implicitly creating a new task
at runtime, whereas <foreach> and <antcall> are tasks that use parameters
during their runtime. It's two different things, and again the meaning
should not be overloaded.

Please consider using <attribute> instead of <param>, re-enforcing this idea
that <macrodef> create a new task, as the same time that (@name)
re-enforcement the fact that it's not a regular property dereference.

Thanks, --D

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message