Scott, I'd really prefer to branch on this - it has the ability to really break things. One of the first changes is changing the PropertyDictionary to to store Property objects instead of string values. The property object is where the accessibility level is stored.
While I am really keen to put this in, I realise that this may not be stable before the next release. One of the key drivers for the scoped properties (for me anyway) is the inline task definitions. That's why I wanted to see them together. Scoped properties would need to be implemented first mind. ---------------------------------------- - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Hernandez Sent: Thursday, 22 January 2004 7:37 AM To: [EMAIL PROTECTED] Subject: Re: [nant-dev] Property Scoping Seems like the "flow" scope should be called "local" in C#/programming terms, and local would be private/container-only scoping. Having "global" be the default is a good call, but only in come case, as you have identified in <if/>/<foreach/>/etc. I'm sure we will be able to say more with a patch; so we can test things out. If the changes are small enough, and defaults don't change existing functionality, I'm happy to put them in the head since we are still a little while from testing/beta'n this version. I'd be inclined to separate the two patches, one for scoped properties (which are core changes) and one for the new task def stuff. ----- Original Message ----- From: "Mitch Denny" <[EMAIL PROTECTED]> > Hi folks, > > OK, I've got a bit of a prototype working for property scoping which so > far appears to be non-breaking to existing scripts. It works like this: > > <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}" /> > > 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> > > 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 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. > > Can I get a +1 or -1? ------------------------------------------------------- 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 ------------------------------------------------------- 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
