On Wednesday 19 November 2003 09:46, Stefan Bodewig wrote:
> On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> >> Your proposal uses a <local> task that sets up a local scope for a
> >> named property until the enclosing target/sequential finishes.
> >> Jose Alberto suggested to use a <local> TaskContainer instead,
> >> something like
> >
> > I think that this looks clumsy.
>
> possible - I'm not afraid of looking clumsy 8-) This is IMHO a case
> where verbosity is a win.
>
> > (note as well that local-property is not a valid name,
>
> Why not? Nothing's going to stop my from taskdeffing that name and
> <local> is a TaskContainer.
Correct, I just assumed that as local-property element only made sense in
your example as an nested element of the <local> and hense was a result of
an add/create<Name>() introspection method.
> Anyway, I'm in no way attached to any
> name, I would even be fine with <let> as the name of the container,
> but I'm afraid that not too many users would recognize this.
Or worst, too many users may recognize it...
>
> >> (2) Shadowing of properties
> >>
> >> I think they shouldn't be allowed to override any outer scope
> >> properties at all.
> >
> > I think that this will reduce their usefullness a lot.
>
> Maybe. It would be enough to isolate macrodef invocations from each
> other, though.
>
> Allowing them to override "plain" properties opens up the "properties
> are immutable" rule and makes it a "properties are immutable unless
> overridden in a <local>".
It does not (in my opinion) do this anymore that using <antcall>
with <param> nested elements.
<target name="docall">
<property name="x" value="global"/>
<antcall target="othertarget">
<param name="x" value="different value than '${x}'"/>
</antcall>
</target>
> This even stronger asking for a
> TaskContainer IMHO.
>
> What is your usecase for overriding properties?
Mysterious failures of macro's because some build file's use
a particular property name and others do not.
Normally people use short names for local variables - file, text etc.
They could be used at the different scopes.
Also recursive macrodefs would have a problem:
<macrodef name="recur">
<attribute name="number"/>
<sequential>
<localpropertycontainer>
<echo>number is @{number}</echo>
<localproperty name="mynumber"/>
<ac:math
datatype = "int"
result = "mynumber"
operand1 = "@{number}"
operation = "-"
operand2 = "1"
/>
<ac:if>
<ac:equals arg1="0" arg2="${mynumber}"/>
<ac:then>
<echo>Done</echo>
</ac:then>
<ac:else>
<recur number="${mynumber}"/>
</ac:else>
</ac:if>
</localpropertycontainer>
</sequential>
</macrodef>
(ok, maybe "localpropertycontainer" is a bit much)
>
> > The idea of not overridding user properties comes from the <ant>
> > family behaviour,
>
> Not only. Even setProperty will not override a use property.
Ok, the idea actually came for your previous e-mail pointing this out ....
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
