Hiya Jarek, Yeah I wasn't sure about the nested if approach either, its easy enough to change the behavior (I think). By default its Global anyway, and flow fits the bill. Maybe Local should behave like Flow, and have one called Private or something. Shrug :)
Come to think of it, there are very few cases where you wouldn't want to use either Global or Flow instead of Local. Need to think about where we want "Flow" properties to fall out of scope and cross breed it with Local. ---------------------------------------- - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -----Original Message----- From: Jaroslaw Kowalski [mailto:[EMAIL PROTECTED] Sent: Thursday, 22 January 2004 6:37 AM To: Mitch Denny; [EMAIL PROTECTED] Subject: Re: [nant-dev] Property Scoping 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
