On Fri, 10 Sep 2004, Ian MacLean <[EMAIL PROTECTED]> wrote:
> I was under the impression that Ant properties also have global
> scope but maybe this has changed recently.
They are.
> If this is still true then I wonder how the parallel task in Ant
> works around it.
It doesn't, really. But the
>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
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. N
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, t
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 essentiall
> 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
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 essent
> > 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) ...
Yes, I agree that 1.0 is more
- Original Message -
From: "Ian MacLean" <[EMAIL PROTECTED]>
To: "Jaroslaw Kowalski" <[EMAIL PROTECTED]>
Cc: "Mitch Denny" <[EMAIL PROTECTED]>; "Scott Hernandez"
<[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thurs
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 mu
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 wha
> 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 stri
> > 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 +
I think we had talked about this before and just didn't flush it out enough.
If I remember correctly we were in support of it.
I'd like to see some more discussion about it, and the consequences, before
we move forward, but I'd give it a tentative +!.
It definitely fits in with a typed expression
> 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
-
-
-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
> 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 goo
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
onash.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!
>
>
> Global is actually the default. If I had this
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
//etc.
I'm sure we will be able to say more with a patch; so we can test
Hi Mitch!
>
>
> Global is actually the default. If I had this:
>
>
>
> 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 expres
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:
Global is actually the default. If I had this:
It would mean that the property is accessible to all things in the
current
22 matches
Mail list logo
