Re: [nant-dev] Property Scoping
From: Ian MacLean [EMAIL PROTECTED] Sent: Friday, September 10, 2004 1:12 AM If this is still true then I wonder how the parallel task in Ant works around it. Properties in Ant are always read-only, so there shouldn't be any issue unless two parallel tasks attempt to create the same new property - an unlikely scenario. Gary --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
Re: [nant-dev] Property Scoping
Andy Sipe wrote: I'm in the process of implementing a parallel type task (similiar to the existing Ant task). I've pretty much got it working and was playing with it in our current build file. The first thing I found was that properties that are declared within a target are global in scope. Needless to say, this caused a lot of problems when targets began to run at the same time. I did a bit of snooping in the archives and found that at one point (http://www.mail-archive.com/[EMAIL PROTECTED]/msg03300.html) there was talk of having the ability to scope properties to a given target vs being global. Has this been implemented in any way? No - not yet. I think we had basically decided that there was no pressing need for scoped properties. Perhaps you've just found one. I was under the impression that Ant properties also have global scope but maybe this has changed recently. From Ant - the definitive guide: the other prominent property characteristic is that properties are always global in scope. If this is still true then I wonder how the parallel task in Ant works around it. Ian -- Ian MacLean, Developer, ActiveState, a division of Sophos http://www.ActiveState.com --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 13. Go here: http://sf.net/ppc_contest.php ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Property Scoping
What about scoped properties? - Mitch Denny - [EMAIL PROTECTED] - http://www.monash.net - +61 (414) 610141 - -Original Message- From: Ian MacLean [mailto:[EMAIL PROTECTED] Sent: Friday, 23 January 2004 7:07 AM To: Jaroslaw Kowalski Cc: Mitch Denny; Scott Hernandez; [EMAIL PROTECTED] Subject: Re: [nant-dev] Property Scoping To be honest I'd like to see us release a 1.0 with the current feature set before implementing somthing like typed properties. it would be kinda nice to unify properties and type references which are both essentially different types of variables. However I do feel that this is peripheral to what the majority of users want to do with nant. ie its quite a big change which doesn't actually make that much of a user-visible difference in many cases. Not that its not worth investigating just that it might be sensible to set this out past a 1.0 release. Ian Jaroslaw Kowalski wrote: Yeah, I was considering the same thing. I also wondered whether this could mean that there could be a unified type system. Filesets, string properties etc. You mean storing a fileset inside a property? Interesting idea. Gert, Ian, Scott - what do you think about typed properties? 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 --- 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
Re: [nant-dev] Property Scoping
To be honest I'd like to see us release a 1.0 with the current feature set before implementing somthing like typed properties. Agree. Still I'd like to see some verbosity patch and fileset extensions in 1.0 somehow. Hope those will find its way into 1.0 even they are not in release plan. it would be kinda nice to unify properties and type references which are both essentially different types of variables. However I do feel that this is peripheral to what the majority of users want to do with nant. ie its quite a big change which doesn't actually make that much of a user-visible difference in many cases. Not that its not worth investigating just that it might be sensible to set this out past a 1.0 release. To yours 2nd mail: Sure this is clean in a mathematical sense but personally I'd rather see a more verbose layout that actually gives me an idea of what files the fileset will match just by looking at it. Given that it can be hard to determine what a given fileset will match right now I imagine it will be that much more difficult trying to work out the result after a difference operation has been performed. Agree. I have more and more feeling that just add includes refid=/ into fileset should be enough. It is not type-general but... Martin --- 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
Re: [nant-dev] Property Scoping
Yeah, I was considering the same thing. I also wondered whether this
could mean that there could be a unified type system. Filesets, string
properties etc.
You mean storing a fileset inside a property? Interesting idea.
Oh - we already mention it before. Would be great! And also + operator in
expressions could be overriden to fileset merge :) And functions with
fileset argument could exists instead of string as refid to fileset etc etc
etc...
Still we should be compatible with current id= syntax so typedefs should
define property of its type?
Sum: +1 for it!
btw: maybe we will find some nicer syntax for merging here? e.g.
property type=fileset name=id1 value=${id1+id2}/
Gert, Ian, Scott - what do you think about typed properties?
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
---
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
Re: [nant-dev] Property Scoping
Oh - we already mention it before. Would be great! And also + operator in
expressions could be overriden to fileset merge :) And functions with
fileset argument could exists instead of string as refid to fileset etc
etc
etc...
The overload is a bad idea. Currently it has problems with strings
(concatenation) vs anything else (addition) and adding another exception
would be even more confusing.
Still we should be compatible with current id= syntax so typedefs should
define property of its type?
That would be consistent. We'd have a single build state
(PropertyDictionary) instead of PropertyDictionary for simple values +
DataTypeBaseDictionary for complex values.
Sum: +1 for it!
btw: maybe we will find some nicer syntax for merging here? e.g.
property type=fileset name=id1 value=${id1+id2}/
I would propose:
property name=id1 type=fileset value=${fileset::union(fs1, fs2)} /
property name=id1 type=fileset value=${fileset::intersection(fs1,
fs2)} /
property name=id1 type=fileset value=${fileset::difference(fs1, fs2)}
/
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
Re: [nant-dev] Property Scoping
To be honest I'd like to see us release a 1.0 with the current feature set before implementing somthing like typed properties. it would be kinda nice to unify properties and type references which are both essentially different types of variables. However I do feel that this is peripheral to what the majority of users want to do with nant. ie its quite a big change which doesn't actually make that much of a user-visible difference in many cases. Not that its not worth investigating just that it might be sensible to set this out past a 1.0 release. Ian Jaroslaw Kowalski wrote: Yeah, I was considering the same thing. I also wondered whether this could mean that there could be a unified type system. Filesets, string properties etc. You mean storing a fileset inside a property? Interesting idea. Gert, Ian, Scott - what do you think about typed properties? 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 --- 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
Re: [nant-dev] Property Scoping
Sure this is clean in a mathematical sense but personally I'd rather see
a more verbose layout that actually gives me an idea of what files the
fileset will match just by looking at it. Given that it can be hard to
determine what a given fileset will match right now I imagine it will be
that much more difficult trying to work out the result after a
difference operation has been performed.
Ian
I would propose:
property name=id1 type=fileset value=${fileset::union(fs1, fs2)} /
property name=id1 type=fileset value=${fileset::intersection(fs1,
fs2)} /
property name=id1 type=fileset value=${fileset::difference(fs1, fs2)}
/
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
---
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
Re: [nant-dev] Property Scoping
- Original Message - From: Ian MacLean [EMAIL PROTECTED] To: Jaroslaw Kowalski [EMAIL PROTECTED] Cc: Mitch Denny [EMAIL PROTECTED]; Scott Hernandez [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Thursday, January 22, 2004 9:07 PM Subject: Re: [nant-dev] Property Scoping To be honest I'd like to see us release a 1.0 with the current feature set before implementing somthing like typed properties. I agree completely on this subject. There are things that are much more urgent than this (have a look at the releaseplan) ... Gert --- 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
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
RE: [nant-dev] Property Scoping
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
RE: [nant-dev] Property Scoping
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
RE: [nant-dev] Property Scoping
Hiya,
Yeah, I was considering the same thing. I also wondered whether this
could mean that there could be a unified type system. Filesets, string
properties etc.
- Mitch Denny
- [EMAIL PROTECTED]
- http://www.monash.net
- +61 (414) 610141
-
-Original Message-
From: Jaroslaw Kowalski [mailto:[EMAIL PROTECTED]
Sent: Thursday, 22 January 2004 7:50 AM
To: Mitch Denny; Scott Hernandez; [EMAIL PROTECTED]
Subject: Re: [nant-dev] Property Scoping
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.
The branch is a good idea. I'd like to evaluate another issue: can we
have TYPED properties? Like this:
property name=counter type=integer value=0 /
This way you can write:
if test=${counter + 1 = 100}
/if
instead of:
if test=${convert::to-int(counter) + 1 = 100} /if
Once a property has its type set, it cannot be re-typed. Every time you
store a value in such a property, it is checked for type compatibility.
Storing data type (optional - would default to string) in a
PropertyDictionary would help here a lot.
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
