On Thursday 14 August 2003 15:23, Dominique Devienne wrote:
> After all the praises, I hope my post doesn't sound too negative.
No problem.
> I also
> think it's a great addition Peter, I just have a few reservations ;-)
>
> See below... --DD
>
> > -----Original Message-----
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> >
> > <presetdef> (formally known as extendtype)
> > this defines a new task or type based on a current ant task or type,
> > with attributes or elements preset.
> >
> > example useage:
> > <presetdef name="my.javac">
> > <javac debug="${debug}" deprecation="${deprecation}"/>
> > </presetdef>
> >
> > <my.javac> may now be used as a task in the same way as <javac>
> > but the attribute debug and deprecation will be preset.
>
> I'll start by neat picking ;-) What <presetdef> does is binding a given
> value to a task attribute. In the C++ world, the method to do that are call
> bind, which is IMHO better that preset.
<presetdef/> also allows nested elements to be predefined - or bound.
> Also, this kind of static attribute-binding is useful indeed (I've actually
> asked for it a few times), but is hardly a definition, and it's bad that it
> forces you to rewrite the task name. I don't want to modify all my builds
> to use <my.javac> just to take advantage of that feature.
>
> Finally, <presetdef>, in term of functionality and not implementation, is
> just a subset of <macrodef> in my opinion, and doesn't deserve Task status.
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"/>
>
> Much more useful IMO was be the ability to bind (or preset) values using
> XPath expressions, to follow your example:
>
> //javac/@debug = ${debug}
> //javac/@deprecation = ${deprecation}
>
> To just do it for an instance of Javac inside a particular target, do
>
> //[EMAIL PROTECTED]'compile']/javac/@debug = true
>
> I've always been annoyed to having to explicitly declare a bunch of task
> attributes taking properties when sensible default values just to be able
> to maybe override them.
>
> So in conclusion, I'm +1 to the ability to bind values to task/type
> attributes, but without requiring task name changes, and possibly with
> requiring a task. I'm -0 to <presetdef> as it is.
>
> 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/>.
> > <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*. 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.
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.
* This is different to <expandtype> where the project of the definer
is used to evaluate the preset attributes and elements.
This is a reason I called the second task <macrodef/>, one
should consider it a lump of xml to be placed in at the current
location with substitutions of attributes and elements.
> I think we need another syntax for the macro
> param/attributes, and keep the ${} working as usual.
>
> I propose to use either:
> * the XSL syntax (@name)
> * or a Javadoc-like syntax [EMAIL PROTECTED] name}
>
> 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.
>
> 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.
* Locally I have modified foreach to behave the same way as macrodef,
(i.e run a sequential task in the same project with the different values of
the list or path)
Cheers Peter.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
