On Thursday 23 October 2003 14:09, Stefan Bodewig wrote:
> On Thu, 23 Oct 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > The following does the same ......
> >
> > <target name="i-have-won-over-gump">
> > <antcall target="j">
> > <param name="build.sysclasspath" value="ignore"/>
> > </antcall>
> > </target>
>
> It doesn't - if build.sysclasspath is a user property of course. Try
> it with ant -Dbuild.sysclasspath=only and you'll see.
Opps..
You are right.
In this case, dynamic extent for local/attributes does not make
sense if attributes allow shadowing of user properties.
<target name="i-have-won-over-gump">
<macrodef name="shadow">
<attribute name="build.sysclasspath" default="ignore"/>
<attribute name="target"/>
<sequential>
<antcall target="${target}"/>
</sequential>
</macrodef>
<shadow target="j"/>
</target>
> At least Emacs Lisp uses dynamic extent here, i.e. with
>
> (setq here bar)
> (let ((here foo))
> (some-method))
>
> the function some-method would see the value foo for 'here.
Oh, yes that must be true from a lisp point of view.
> I'm not familiar enough with other Lisp dialects. So if you want to
> draw this parallel, <ant> would have to inherit the local shadows.
> And <macrodef> would see the same problems (defmacro) has and we'd
> have to introduce "uninterned symbols" to solve some issues,
> (i.e. properties that are no properties at all). In a sense,
> <macrodef>'s current attributes are such uninterned symbols.
Yikes, that sounds complicated.
> > This is done to support the following:
> > <local name="x"/>
> > <parallel>
> > <sequential>
> > <property name="x" value="1"/>
> > <echo>x is ${x}</echo>
> > </sequential>
> > <sequential>
> > <property name="x" value="2"/>
> > <echo>x is ${x}</echo>
> > </sequential>
> > <sequential>
> > <property name="x" value="3"/>
> > <echo>x is ${x}</echo>
> > </sequential>
> > </parallel>
> Feels wrong. Each sequential should be/contain a <local> IMHO. If
> you want to have different local scopes withon the <sequential>s then
> you have to create them.
Ok, that makes sense, implementation may however be difficult.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
