ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dominique Devienne <DDevie...@lgc.com>
Subject RE: [new tasks] presetdef and macrodef
Date Thu, 14 Aug 2003 16:44:03 GMT
> -----Original Message-----
> From: peter reilly [mailto:peter.reilly@corvil.com]
> 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="org.apache.tools.ant.task.TaskAdaptor"
>                       adaptto="org.apache.tools.ant.task.Task"/>
> </presetdef>
> 
> When (if) roles are introducted, one implementation would be
> to add a "role" or "restrict" attribute to <typedef>.
> 
>   <typedef name="or"
>         classname="org.apache.tools.ant.taskdefs.conditions.Or"
>         restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/>
> 
>   <typedef name="or"
>         classname="org.apache.tools.ant.types.selectors.Or"
>         restrict="org.apache.tools.ant.types.selectors.FileSelector"/>
> 
> one could use <presetdef/> as
>    <presetdef name="conditiondef">
>        <typedef
>            restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/>
>     </presetdef>
> 
> and define:
>     <conditiondef name="or"
>            classname="org.apache.tools.ant.taskdefs.conditions.Or"/>

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

<macrodef name="conditiondef">
  <typedef restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/>
</macrodef>

and still do, 

<conditiondef name="or"
              classname="org.apache.tools.ant.taskdefs.conditions.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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message