On Thursday 14 August 2003 17:44, Dominique Devienne wrote:
> > -----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>
> >
>
> 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"/>
No, you cannot do this.
In this case <macrodef/> has defined no attributes for "conditiondef"
so the name and classname will be rejected.
One could do
<macrodef name="conditiondef">
<attribute name="name"/>
<attribute name="classname"/>
<sequential>
<typedef
name="${name}" classname="${classname}"
restrict="org.apache.tools.ant.taskdefs.conditions.Condition"/>
</sequential>
</macrodef>
But one would need to do similar things for the other attributes and nested
elements.
>
> 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!!!
What I am saying is that even with a different notation for
attributes, normal property resolution will take place in the context
of the user of the macro, and not when the macro is defined. This
is a consequence of the way <macrodef/> is implemented, in particualar
to support embedded elements.
>
> > 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).
As a temporary measure I have added a new attribute "attributestyle" to
allow the notatation to be specified. The attribute can be "ant" (default)
or "xpath". This should allow people to experiment with either
formats, and we could choose one later.
>
> > > 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?
The checks (i.e. are the attributes/elements present) are done when the
macro is used.
>
> > > 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.
I have changed the name of the element to <attribute>. (I found that
this name is used by <scriptdef> so it has presedence.)
Cheers
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
