> -----Original Message-----
> From: peter reilly [mailto:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
