Hi Mitch!
> <property name="x" value="y" accessibility="Global" />
>
> Global is actually the default. If I had this:
>
> <property name="x" value="y" accessibility="Local" />
>
> It would mean that the property is accessible to all things in the
> current scope where a scope is defined by the current target (project
> for root level tasks) or TaskContainer. So this would cause an error in
> the expression evaluator:
>
> <if test="true">
> <property name="x" value="y" accessibility="Local" />
> </if>
>
> <echo message="${x}" />
That's intuitive. You usually expect variable to be inaccessible when it
leaves the scope.
>
> Because x is not accessible outside of the scope defined by the if task
> container. This works with my earlier taskdef work too! Interestingly
> the following won't work.
>
> <if test="true">
> <property name="x" value="y" accessibility="Local" />
> <if test="true">
> <echo message="${x}" />
> </if>
> </if>
This one is counter-intuitive. Most languages use "local" for what you've
called "flow". What is the use for local scoping anyway?
> Because local is local to the current task container. I introduced a
> third accessibility level called Flow which allows this to work.
> Remember that the default is Global when you are using the <property />
> task, so it won't break anything. The way it works is that I have lots
> of PropertyDictionary objects attached to a hierarchy of Scope objects.
> The scope is updated when ever a build/target/task container starts or
> finishes.
I haven't noticed a patch attached, but I don't know why do you want to
store multiple dictionaries? Usually the this kind of processing can be done
entirely on the evaluation stack.
> I also modified quite a bit of the implementation of PropertyDictionary
> so that it now stores a Property object as its value although the
> external interface is unaffected (cross fingers I didn't break
> anything).
> Now that I have done this, and if there is enough interest I'd like to
> propose that we do something like has been done for expression
> evaluation, take a branch and do some exploritory work on this where
> this = <taskdef /> and property scoping.
This definitely needs some thought. +1 for the branch idea.
>
> Can I get a +1 or -1?
+2/3
Jarek
-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
nant-developers mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/nant-developers
