> From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
>
> On Mon, 21 Jun 2004, Jose Alberto Fernandez
> <[EMAIL PROTECTED]> wrote:
>
> > basically, I think we need to decide (by taking into account the
> > consequences) if this local properties ARE properties or
> are something
> > else that look like properties.
>
> Unless we want to change all property setting tasks, they
> have to be real properties IMHO. The main limitation I see
> without local properties in <macrodef> is when your macro
> uses a property setting task like <basename> or <available> -
> you currently need to provide a unique property name to those
> tasks if you want to reuse the macro.
>
Is this really the only reason, currently, for local properties?
Because if that is the case, maybe we can solve the problem in a
completely different way, which is specific to <macrodef/>.
For example, we could have a new kind of @{thing} whose value
is not passed as an attribute but guaranteed to be unique on the live
of the JVM. So a macrodef can generate as many new names as are required
and the programmer refers to them by local @{names}. E.g.:
<macrodef name="example">
<attribute name="foo"/>
<let name="basefoo"/>
<sequential>
<basename property="@{basefoo}" file="@{foo}"/>
<echo massage="[EMAIL PROTECTED]"/>
</sequential>
</macrodef>
By making sure that <let/> produces new names across the JVM from a
well known name-space, we can solve the problem, although poluting
the set of properties available during the build.
But everything will be just as it is today and there is no need for any
new feature of ANTCore, just of <macrodef/>.
What do people think?
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
