RE: [VOTE] local for 1.6
> From: Steve Loughran [mailto:[EMAIL PROTECTED] > > > It would seem better to get this right before we ship, as then things > stay broken. Holding stuff over to 1.7 lets us experiment > with the model > more before we actually ship. But I agree, without it, > macrodef is more > limited. > Well, it is no more or less limited than cutting and pasting tasks. And if the implementation is circumscribed enough, it should be able to be added as an add-on on a point-release of 1.6. I.e., we do not need to wait for a year to get it. Jose Alberto > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with (was Re: [VOTE] local for 1.6)
On Wednesday 19 November 2003 09:46, Stefan Bodewig wrote:
> On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote:
> > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> >> Your proposal uses a task that sets up a local scope for a
> >> named property until the enclosing target/sequential finishes.
> >> Jose Alberto suggested to use a TaskContainer instead,
> >> something like
> >
> > I think that this looks clumsy.
>
> possible - I'm not afraid of looking clumsy 8-) This is IMHO a case
> where verbosity is a win.
>
> > (note as well that local-property is not a valid name,
>
> Why not? Nothing's going to stop my from taskdeffing that name and
> is a TaskContainer.
Correct, I just assumed that as local-property element only made sense in
your example as an nested element of the and hense was a result of
an add/create() introspection method.
> Anyway, I'm in no way attached to any
> name, I would even be fine with as the name of the container,
> but I'm afraid that not too many users would recognize this.
Or worst, too many users may recognize it...
>
> >> (2) Shadowing of properties
> >>
> >> I think they shouldn't be allowed to override any outer scope
> >> properties at all.
> >
> > I think that this will reduce their usefullness a lot.
>
> Maybe. It would be enough to isolate macrodef invocations from each
> other, though.
>
> Allowing them to override "plain" properties opens up the "properties
> are immutable" rule and makes it a "properties are immutable unless
> overridden in a ".
It does not (in my opinion) do this anymore that using
with nested elements.
> This even stronger asking for a
> TaskContainer IMHO.
>
> What is your usecase for overriding properties?
Mysterious failures of macro's because some build file's use
a particular property name and others do not.
Normally people use short names for local variables - file, text etc.
They could be used at the different scopes.
Also recursive macrodefs would have a problem:
number is @{number}
Done
(ok, maybe "localpropertycontainer" is a bit much)
>
> > The idea of not overridding user properties comes from the
> > family behaviour,
>
> Not only. Even setProperty will not override a use property.
Ok, the idea actually came for your previous e-mail pointing this out
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with (was Re: [VOTE] local for 1.6)
On Tue, 18 Nov 2003, Jose Alberto Fernandez <[EMAIL PROTECTED]> wrote: >> From: peter reilly [mailto:[EMAIL PROTECTED] >> >> On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote: >> >> > >> > >> > >> > > > Just for the record, my syntax was more like: > > > ... > OK, I didn't actually check. > Which does not need inner special elements (less clumsy) but it > requires one nesting per property (but really, how many locals > would you have one after the other?) I'm not sure, I could live with both, nested elements as well as multiple containers. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with (was Re: [VOTE] local for 1.6)
On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote: >> Your proposal uses a task that sets up a local scope for a >> named property until the enclosing target/sequential finishes. >> Jose Alberto suggested to use a TaskContainer instead, >> something like > > I think that this looks clumsy. possible - I'm not afraid of looking clumsy 8-) This is IMHO a case where verbosity is a win. > (note as well that local-property is not a valid name, Why not? Nothing's going to stop my from taskdeffing that name and is a TaskContainer. Anyway, I'm in no way attached to any name, I would even be fine with as the name of the container, but I'm afraid that not too many users would recognize this. >> (2) Shadowing of properties >> >> I think they shouldn't be allowed to override any outer scope >> properties at all. > > I think that this will reduce their usefullness a lot. Maybe. It would be enough to isolate macrodef invocations from each other, though. Allowing them to override "plain" properties opens up the "properties are immutable" rule and makes it a "properties are immutable unless overridden in a ". This even stronger asking for a TaskContainer IMHO. What is your usecase for overriding properties? > The idea of not overridding user properties comes from the > family behaviour, Not only. Even setProperty will not override a use property. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with (was Re: [VOTE] local for 1.6)
On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > On Tuesday 18 November 2003 15:53, peter reilly wrote: > >> me) more natural. However, I can see benefits ;- my code may not > Opps that should of course be "the" code and not "my" code. Don't worry 8-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] local for 1.6
peter reilly wrote:
(hopefully this should be the final feature vote for 1.6)
The local feature allows local properties - properties
that are valid only for the enclosing scope.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942
This is a useful feature in general and for macrodef in particular.
For example the macrodef in Stefan's blog:
http://stefanbodewig.blogger.de/20031114
may be implemented by:
Couldn't find ${class}
Vote:
[ -0] local for ant 1.6
[ +0] wait for ant 1.7
It would seem better to get this right before we ship, as then things
stay broken. Holding stuff over to 1.7 lets us experiment with the model
more before we actually ship. But I agree, without it, macrodef is more
limited.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with (was Re: [VOTE] local for 1.6)
On Tuesday 18 November 2003 18:14, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote:
> > > My major issue with the current implementation proposal is that it
> > > touches way too many places in the code. It needs to change the
> > > implemention of almost all the usages of sequential (and target).
> >
> > This is not quite true. It does change the implementation of
> > target and task but usage of these should not need to change.
> > For example ant-contrib has a task with a
> > element. This works correctly as a local block
> > without any changes to the implementation of Outofdate:
> >
> >
> >
> >
> >
> >
> >
> >
> > l is '${l}'
> >
> >
> >
> >
> > prints out "l in 'in outofdate'".
>
> Would it work if my task extends Sequential?
> How about if my task just implements TaskContainer interface?
Yes.
>
> By having just a regular task that controls the feature there
> is less room for confusion between which tasks do provide
> access to the feature and which do not.
True.
>
> For example, what is the effect of having something like this:
> Assume I have a task that accepts as an element a task. It does not
> uses sequential, just gets the task element and executes it.
I this case it would need to be a TaskContainer.
> What happens if I pass a declaration as the element?
> What would be the lifetime of the property being defined?
The lifetime of the container.
> Can we make sure the span is just the execution of the itself?
> What if I just create a task using script? Can I violate
> the scoping rules by doing things like that?
In all cases, the local will exist for the span of the containing
container. With script one can do all sorts of silly things
>
> With the ... version, there are no issues, because the
> scope is syntactically defined by the task itself.
>
> Hope this is compelling enough.
Cheers,
Peter
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: My itches with (was Re: [VOTE] local for 1.6)
> From: peter reilly [mailto:[EMAIL PROTECTED]
>
> On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote:
> >
> > My major issue with the current implementation proposal is that it
> > touches way too many places in the code. It needs to change the
> > implemention of almost all the usages of sequential (and target).
>
> This is not quite true. It does change the implementation of
> target and task but usage of these should not need to change.
> For example ant-contrib has a task with a
> element. This works correctly as a local block
> without any changes to the implementation of Outofdate:
>
>
>
>
>
>
>
>
> l is '${l}'
>
>
>
>
> prints out "l in 'in outofdate'".
>
Would it work if my task extends Sequential?
How about if my task just implements TaskContainer interface?
By having just a regular task that controls the feature there
is less room for confusion between which tasks do provide
access to the feature and which do not.
For example, what is the effect of having something like this:
Assume I have a task that accepts as an element a task. It does not
uses sequential, just gets the task element and executes it.
What happens if I pass a declaration as the element?
What would be the lifetime of the property being defined?
Can we make sure the span is just the execution of the itself?
What if I just create a task using script? Can I violate
the scoping rules by doing things like that?
With the ... version, there are no issues, because the
scope is syntactically defined by the task itself.
Hope this is compelling enough.
Jose Alberto
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with (was Re: [VOTE] local for 1.6)
On Tuesday 18 November 2003 17:05, Jose Alberto Fernandez wrote:
> > From: peter reilly [mailto:[EMAIL PROTECTED]
> >
> > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote:
> > > Things we need to consider IMHO:
> > >
> > > (1) Syntax
> > >
> > > Your proposal uses a task that sets up a local scope for a
> > > named property until the enclosing target/sequential
> >
> > finishes. Jose
> >
> > > Alberto suggested to use a TaskContainer instead, something
> > > like
> > >
> > >
> > >
> > >
>
> Just for the record, my syntax was more like:
>
>
> ...
>
>
> Which does not need inner special elements (less clumsy) but it
> requires one nesting per property (but really, how many locals
> would you have one after the other?)
>
> > > which would essentially just add an explicit (and
> >
> > differently named)
> >
> > > to your proposal. I think I prefer the more explicit,
> > > even if more verbose syntax of the second form.
> >
> > I think that this looks clumsy. Making local's valid for the
> > current block scope (target level, or sequential level) feels (to
> > me) more natural. However, I can see benefits ;- my code may
> > not catch all uses of sequential.
>
> My major issue with the current implementation proposal is that
> it touches way too many places in the code. It needs to change the
> implemention of almost all the usages of sequential (and target).
This is not quite true. It does change the implementation of
target and task but usage of these should not need to change.
For example ant-contrib has a task with a
element. This works correctly as a local block without any changes to the
implementation of Outofdate:
l is '${l}'
prints out "l in 'in outofdate'".
> In my design it should only touch itself and the datastructures
> for property handling (given that we want to use threadlocals).
>
> It is a very much less footprint and that I think is good.
>
> > (note as well that local-property is not a valid name,
> > localproperty would be correct).
> >
> > > (2) Shadowing of properties
> > >
> > > Your updated proposal ensures that local properties do not override
> > > "global" user properties. I think they shouldn't be allowed to
> > > override any outer scope properties at all.
> >
> > I think that this will reduce their usefullness a lot. The
> > idea of not overridding user properties comes from the
> > family behaviour, but they can overriden other properties.
>
> Agreed, if I cannot override properties, what was the point of all this
> discussion?
> The proposal always allowed to override properties.
>
> > > (3) Extent of local properties
> > >
> > > You make the local properties available to
RE: My itches with (was Re: [VOTE] local for 1.6)
> From: peter reilly [mailto:[EMAIL PROTECTED] > > On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote: > > > > Things we need to consider IMHO: > > > > (1) Syntax > > > > Your proposal uses a task that sets up a local scope for a > > named property until the enclosing target/sequential > finishes. Jose > > Alberto suggested to use a TaskContainer instead, something > > like > > > > > > > > > > Just for the record, my syntax was more like: ... Which does not need inner special elements (less clumsy) but it requires one nesting per property (but really, how many locals would you have one after the other?) > > which would essentially just add an explicit (and > differently named) > > to your proposal. I think I prefer the more explicit, > > even if more verbose syntax of the second form. > > I think that this looks clumsy. Making local's valid for the > current block scope (target level, or sequential level) feels (to > me) more natural. However, I can see benefits ;- my code may > not catch all uses of sequential. > My major issue with the current implementation proposal is that it touches way too many places in the code. It needs to change the implemention of almost all the usages of sequential (and target). In my design it should only touch itself and the datastructures for property handling (given that we want to use threadlocals). It is a very much less footprint and that I think is good. > (note as well that local-property is not a valid name, > localproperty would be correct). > > > (2) Shadowing of properties > > > > Your updated proposal ensures that local properties do not override > > "global" user properties. I think they shouldn't be allowed to > > override any outer scope properties at all. > > I think that this will reduce their usefullness a lot. The > idea of not overridding user properties comes from the > family behaviour, but they can overriden other properties. > Agreed, if I cannot override properties, what was the point of all this discussion? The proposal always allowed to override properties. > > > > (3) Extent of local properties > > > > You make the local properties available to
Re: My itches with (was Re: [VOTE] local for 1.6)
On Tuesday 18 November 2003 15:53, peter reilly wrote: > me) more natural. However, I can see benefits ;- my code may not Opps that should of course be "the" code and not "my" code. Peter - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: My itches with (was Re: [VOTE] local for 1.6)
On Tuesday 18 November 2003 15:32, Stefan Bodewig wrote: > On 18 Nov 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > > On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > >> Vote: > >> [X] local for ant 1.6 > >> [ ] wait for ant 1.7 > > > > and done right ;-) Ouch ;-) > > Things we need to consider IMHO: > > (1) Syntax > > Your proposal uses a task that sets up a local scope for a > named property until the enclosing target/sequential finishes. Jose > Alberto suggested to use a TaskContainer instead, something > like > > > > > > which would essentially just add an explicit (and differently named) > to your proposal. I think I prefer the more explicit, > even if more verbose syntax of the second form. I think that this looks clumsy. Making local's valid for the current block scope (target level, or sequential level) feels (to me) more natural. However, I can see benefits ;- my code may not catch all uses of sequential. (note as well that local-property is not a valid name, localproperty would be correct). > (2) Shadowing of properties > > Your updated proposal ensures that local properties do not override > "global" user properties. I think they shouldn't be allowed to > override any outer scope properties at all. I think that this will reduce their usefullness a lot. The idea of not overridding user properties comes from the family behaviour, but they can overriden other properties. > > (3) Extent of local properties > > You make the local properties available to
My itches with (was Re: [VOTE] local for 1.6)
On 18 Nov 2003, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > >> Vote: >> [X] local for ant 1.6 >> [ ] wait for ant 1.7 > > and done right ;-) Things we need to consider IMHO: (1) Syntax Your proposal uses a task that sets up a local scope for a named property until the enclosing target/sequential finishes. Jose Alberto suggested to use a TaskContainer instead, something like which would essentially just add an explicit (and differently named) to your proposal. I think I prefer the more explicit, even if more verbose syntax of the second form. (2) Shadowing of properties Your updated proposal ensures that local properties do not override "global" user properties. I think they shouldn't be allowed to override any outer scope properties at all. (3) Extent of local properties You make the local properties available to
Re: [VOTE] local for 1.6
On Tue, 18 Nov 2003, peter reilly <[EMAIL PROTECTED]> wrote: > Vote: > [X] local for ant 1.6 > [ ] wait for ant 1.7 and done right ;-) Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [VOTE] local for 1.6
(hopefully this should be the final feature vote for 1.6)
The local feature allows local properties - properties
that are valid only for the enclosing scope.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=23942
This is a useful feature in general and for macrodef in particular.
For example the macrodef in Stefan's blog:
http://stefanbodewig.blogger.de/20031114
may be implemented by:
Couldn't find ${class}
Vote:
[ ] local for ant 1.6
[ ] wait for ant 1.7
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
