RE: macrodef and local
From: Matt Benson [mailto:[EMAIL PROTECTED] --- Magesh Umasankar [EMAIL PROTECTED] wrote: From: Peter Reilly peter.reilly () corvil ! com Date: 2004-06-23 16:23:48 are some cases where true local properties would be more easily like...? like anytime you have to make two passes at some data to get a property set exactly the way you want it. Or you want to pass some data, formatted just so, to a task... MANY TIMES, like for each file in a fileset. Yes, you could write a Java task, or even a scriptdef, but one of the nicest things about macrodef is that anyone familiar with Ant can use it to build more complex behavior out of existing tasks. This could encourage task developers to keep the operations of their tasks as atomic as possible and increase the chance of reusability of pieces. I'm sure I don't need to illustrate the ease-of-use of macrodef vs. using Ant task classes from custom task code? So no, having local variables does not give us anything we can't do, but it does save us having to pollute the Project properties with e.g. 500 useless properties. I am 100% with you on users having to come up with names for 500 diferent properties that they may need internally to their tasks at different points of the build. (I for one have had such a problem). However, if you do not have to come up with such names, and you do not need to be aware of what those names are, do you really care whether these things persists in the execution environment or not. The break task is interesting. I am concerned however about how third party task containers would work with it. If the third-party container would like to support the break task, they would need to catch BreakException and handle it in the place where they iterate over their nested tasks and execute them. BreakException extends from BuildException. It gets thrown by the break task if it decides that the condition to break is met. What if the third-party container would NOT like to support the break task? This starts to change the intent of what a Task does, no? Here I agree. If we were to have such a break/ task I would probably prefer to have it as part of a formal construct and not plugged into the current sequential. For example: block break/ /block I would go a step further and allow desingnating which block to break by something like: block id=a ... block id=b break refid=a/ /block /block This is quite much in the spirit of structured programming and by not overloading sequential/ there is no issue about third party stuff. Of course, the definition of block is quite trivial (just a sequential with a try/catch). And in my opinion BreakException MUST be a subclass of BuildException. Since for example antcontrib:if may not be interested on it. Inside Ant, we'd need to modify Target, Sequential, and Parallel at obvious places to support break Sounds like break is fail with ac:try. If we were going to include flow control, ac:if would require less support programming. I am all for getting some of antcontrib ideas if try switch etc into the mayline. We all use them all the time. That does not mean that we need to accept everything, but I think that with the current level of experience we should be able to pick from there the constructs that people want and use today. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Magesh Umasankar [mailto:[EMAIL PROTECTED] From: Matt Benson gudnabrsam () yahoo ! com Date: 2004-06-23 17:43:46 code? So no, having local variables does not give us anything we can't do, but it does save us having to That is what I was trying to ensure. pollute the Project properties with e.g. 500 useless properties. -0. I don't think the above is a big concern of mine. What if the third-party container would NOT like to support the break task? They wouldn't delegate task execution to TaskContainerUtils.executeTaskList This starts to change the intent of what a Task does, no? No. The task does what it does when it is invoked. The container decides if the task is to be invoked at all. And it is eventually the user who decides that a break is needed and not Ant or any of the task containers. But you are changing the contract of sequential/. If I have a task that inherints from Sequential (under the old contract) now I may get some wird unexpected behavior I never asked for. There are plenty of tasks out there that inherit from sequential because sequential was the most innocuous task out there is just did execution delegation and nothing else. Not it would start making decisions their task were never designed to do. Chhers, Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Jose Alberto Fernandez jalberto () cellectivity ! com Date: 2004-06-24 11:30:33 But you are changing the contract of sequential/. Easy to provide backwards compatibility here - sequential breakable=true/ where breakable is false by default. Similar attributes may be introduced to other behavior altering task containers. Cheers, Magesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Magesh Umasankar [mailto:[EMAIL PROTECTED] From: Jose Alberto Fernandez jalberto () cellectivity ! com Date: 2004-06-24 11:30:33 But you are changing the contract of sequential/. Easy to provide backwards compatibility here - sequential breakable=true/ where breakable is false by default. Similar attributes may be introduced to other behavior altering task containers. I think it is ugly, and there is no reason for modifying sequential/ when you could just as well define a diferent task, like the block/ I proposed. (Not stuck on names, pick a name more of your liking). It is much more easy to write block ... /block than sequential breakable=true ... /sequential Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
--- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Magesh Umasankar [mailto:[EMAIL PROTECTED] [SNIP] Easy to provide backwards compatibility here - sequential breakable=true/ [SNIP] I think it is ugly, and there is no reason for modifying sequential/ when you could just as well define a diferent task, like the block/ I proposed. (Not stuck on names, pick a name more of your liking). It is much more easy to write block ... /block than sequential breakable=true ... /sequential Then we have something like Java labels; this whole concept is starting to sound like something from ant-contrib. -Matt __ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
--- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Matt Benson [mailto:[EMAIL PROTECTED] [SNIP] So no, having local variables does not give us anything we can't do, but it does save us having to pollute the Project properties with e.g. 500 useless properties. [SNIP] However, if you do not have to come up with such names, and you do not need to be aware of what those names are, do you really care whether these things persists in the execution environment or not. Personally, I do care, though as I have already admitted I may be more than a bit neurotic in that respect. Others may not care a bit. -Matt __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Matt Benson [mailto:[EMAIL PROTECTED] --- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Magesh Umasankar [mailto:[EMAIL PROTECTED] [SNIP] Easy to provide backwards compatibility here - sequential breakable=true/ [SNIP] I think it is ugly, and there is no reason for modifying sequential/ when you could just as well define a diferent task, like the block/ I proposed. (Not stuck on names, pick a name more of your liking). It is much more easy to write block ... /block than sequential breakable=true ... /sequential Then we have something like Java labels; this whole concept is starting to sound like something from ant-contrib. Maybe that is where break/ and co. should go. I really -1 the idea of changing sequential/ and add a burden on people that already use and extend that Task just so that break/ (which I preatty much like as an idea) can peggyback part of its functionality on it. It seems wrong to me. I also think several of antcontrib constructs should be migrated to ANTCORE (since they are more than proved their usefulness). But that is a separate battle. So in the mean time, maybe the right thing to do is to implement this functionality in antcontrib and let it mature by allowing people to use and to find any problems away from the core. To me antcontrib should be considered as a sort of laboratory of ideas, and there should be a way for those ideas to migrate back into the core once they have proved their usefulness/pupularity/etc. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
From: Steve Loughran steve_l () iseran ! com
Date: 2004-06-17 9:27:18
I am now convinced we need local properties; without
it macrodef doesnt work fully.
Why do you need them? I typically append an attribute
value to a property name to get the unique property that
I want.
I have had reasonable success with a break task[*]
that compensates for lack of if/unless/depends on
macros.
Cheers,
Magesh
[*]
Syntax: break [if|unless]=property.name/
macrodef name=check-and-do-ejb
attribute name=module
sequential
check-ejb module=@{module}/
break if=@{module}-uptodate/
ejb module=@{module}/
/sequential
/macrodef
(or)
macrodef name=ejb
attribute name=module
sequential
break if=@{module}-uptodate/
...
/sequential
/macrodef
macrodef name=check-and-do-ejb
attribute name=module
sequential
check-ejb module=@{module}/
ejb module=@{module}/
/sequential
/macrodef
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
Magesh Umasankar wrote:
From: Steve Loughran steve_l () iseran ! com
Date: 2004-06-17 9:27:18
I am now convinced we need local properties; without
it macrodef doesnt work fully.
Why do you need them? I typically append an attribute
value to a property name to get the unique property that
I want.
I have had reasonable success with a break task[*]
that compensates for lack of if/unless/depends on
macros.
I see three places where it/unless attributes could be added to macrodef.
1) at the macrodef definition.
macrodef name=showdir if=on.windows
attribute name=dir/
sequential
ac:shellscript script=cmd.exe tmpsuffix=.bat
ac:value=/c/
ac:value=call/
dir @{dir}
/ac:shellscript
/sequential
/macrodef
macrodef name=showdir if=on.linux
sequential
ac:shellscript script=bash
ls -rlta @{dir}
/ac:shellscript
/sequential
/macrodef
2) on the sequential element:
macrodef name=ejb
attribute name=module
sequential unless=@{module}-uptodate
...
/sequential
/macrodef
3) at the macrodef use:
ejb module=x unless=x-uptodate/
Peter
Cheers,
Magesh
[*]
Syntax: break [if|unless]=property.name/
How does this work?
Peter
macrodef name=check-and-do-ejb
attribute name=module
sequential
check-ejb module=@{module}/
break if=@{module}-uptodate/
ejb module=@{module}/
/sequential
/macrodef
(or)
macrodef name=ejb
attribute name=module
sequential
break if=@{module}-uptodate/
...
/sequential
/macrodef
macrodef name=check-and-do-ejb
attribute name=module
sequential
check-ejb module=@{module}/
ejb module=@{module}/
/sequential
/macrodef
-
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: macrodef and local
-1, I think it is a bad idea
From: Peter Reilly [mailto:[EMAIL PROTECTED]
...
I see three places where it/unless attributes could be added
to macrodef.
1) at the macrodef definition.
macrodef name=showdir if=on.windows
attribute name=dir/
sequential
ac:shellscript script=cmd.exe tmpsuffix=.bat
ac:value=/c/
ac:value=call/
dir @{dir}
/ac:shellscript
/sequential
/macrodef
macrodef name=showdir if=on.linux
sequential
ac:shellscript script=bash
ls -rlta @{dir}
/ac:shellscript
/sequential
/macrodef
If we have such a thing, how do I know whether the macro exists at all
or not at my point of use. Whether they do the same or have the same
args.
If there were some form if-else, one would at least know there is some
definintion
for it.
2) on the sequential element:
macrodef name=ejb
attribute name=module
sequential unless=@{module}-uptodate
...
/sequential
/macrodef
So what happens if the property does exists, the definition is empty?
3) at the macrodef use:
ejb module=x unless=x-uptodate/
This probably is the most traditional usage of if/unless I do not
completely
like it but at least is in the spirit of other tasks. But do I need
support
from macrodef, or can I write this myself as part of my macrodef.
I.e., shall macrodef/ hyjack if/unless as reserved attribute names (I
would prefer not).
Another usage of if/unless that may be interesting (not that I am
advocating it or anything)
is at the point of use of elements:
macrodef name=ejb
element name=files/
sequential
doejb
fileset ...
files/
/fileset
/doejb
/sequential
/macrodef
And at the point of use one can write:
ejb
files if=on.windows
/files
files if=on.unix
/files
/ejb
Which will pass the different files/ elements depending of the
properties settings.
Now, the reason I do not like it is because I think we need to put our
effort in some
core way to describe inclusion/exclusion of elements at any level of a
build
(or at least of task) and it should be project-helper the one in charge
of doing it.
This would also include the ideas about having a real expression
language to
specify those inclusions and exclusions.
I think that would be a much more powerful thing to spend our time on
1.7.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
--- Magesh Umasankar [EMAIL PROTECTED] wrote: From: Steve Loughran steve_l () iseran ! com Date: 2004-06-17 9:27:18 I am now convinced we need local properties; without it macrodef doesnt work fully. Why do you need them? I typically append an attribute value to a property name to get the unique property that I want. I cringe at the thought of the number of unique properties that could be floating about resulting from this... -Matt __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Matt Benson [mailto:[EMAIL PROTECTED] --- Magesh Umasankar [EMAIL PROTECTED] wrote: From: Steve Loughran steve_l () iseran ! com Date: 2004-06-17 9:27:18 I am now convinced we need local properties; without it macrodef doesnt work fully. Why do you need them? I typically append an attribute value to a property name to get the unique property that I want. I cringe at the thought of the number of unique properties that could be floating about resulting from this... But do you really care? It is a computer for heaven sake :-) As long as it does not interfere with yours why would it be an issue? On the other hand, if people are writing complicated recursive macrodefs, well it is not like an everyday thing or is it. Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
--- Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Matt Benson [mailto:[EMAIL PROTECTED] --- Magesh Umasankar [EMAIL PROTECTED] wrote: [SNIP] Why do you need them? I typically append an attribute value to a property name to get the unique property that I want. I cringe at the thought of the number of unique properties that could be floating about resulting from this... But do you really care? It is a computer for heaven sake :-) Hmm... I have a suspicion that the goals of computer science and heaven rarely overlap, but that's another discussion. As long as it does not interfere with yours why would it be an issue? With my what? Computer? Other people can do what they like (mostly because I can't stop them), but I prefer a cleaner solution for myself. But I will admit to having what is probably an irrational aversion to existing references to things I no longer care about. I use fewer intermediate variables than probably anyone... :) -Matt __ Do you Yahoo!? Yahoo! Mail is new and improved - Check it out! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
From: Matt Benson gudnabrsam () yahoo ! com Date: 2004-06-23 15:02:54 I cringe at the thought of the number of unique properties that could be floating about resulting from this... Is the user community complaining? The only issue that seems to come up every now and then is lack of straight-forward support like if/unless/depends on macrodef and I'd like to see us address that. I haven't seen a real-world use-case where the only way to solve an issue is by using locals inside macrodef. Hijacking the topic a bit... Instead of adding if unless attributes to macrodef, I suggest adding a new task break that can be placed at arbitrary locations inside a task container to stop further tasks in that container from executing. Cleaner compared to if/then/else constructs and is not tied to macrodef alone. break is smiliar to fail except that it re-routes control to the next task container instead of totally stopping the build process. -Matt Cheers, Magesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
It is not only with macrodef's that folk want if/unless, but macrodef is a bit more obvious because of it's use as a replacement for antcall used as a sub-routine. Using constructed property names is a good work-around for the lack of local properties. But it is a work-around, and there are some cases where true local properties would be more easily be used. The break task is interesting. I am concerned however about how third party task containers would work with it. Peter Magesh Umasankar wrote: From: Matt Benson gudnabrsam () yahoo ! com Date: 2004-06-23 15:02:54 I cringe at the thought of the number of unique properties that could be floating about resulting from this... Is the user community complaining? The only issue that seems to come up every now and then is lack of straight-forward support like if/unless/depends on macrodef and I'd like to see us address that. I haven't seen a real-world use-case where the only way to solve an issue is by using locals inside macrodef. Hijacking the topic a bit... Instead of adding if unless attributes to macrodef, I suggest adding a new task break that can be placed at arbitrary locations inside a task container to stop further tasks in that container from executing. Cleaner compared to if/then/else constructs and is not tied to macrodef alone. break is smiliar to fail except that it re-routes control to the next task container instead of totally stopping the build process. -Matt Cheers, Magesh - 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: macrodef and local
From: Peter Reilly peter.reilly () corvil ! com Date: 2004-06-23 16:23:48 are some cases where true local properties would be more easily like...? The break task is interesting. I am concerned however about how third party task containers would work with it. If the third-party container would like to support the break task, they would need to catch BreakException and handle it in the place where they iterate over their nested tasks and execute them. BreakException extends from BuildException. It gets thrown by the break task if it decides that the condition to break is met. Inside Ant, we'd need to modify Target, Sequential, and Parallel at obvious places to support break Peter Cheers, Magesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
Why would BreakException subclass from BuildException? It's a (heavy) flow control mechanism and has nothing to do with error indication. Just like using try/catch for flow control is not a good idea, break should not piggy back on the build exception mechanism... Also as a developer responsible for lots of task container code, I'm not thrilled with the idea of having to add this hook into every single task... My 2cents. At 01:09 PM 6/23/2004, you wrote: From: Peter Reilly peter.reilly () corvil ! com Date: 2004-06-23 16:23:48 are some cases where true local properties would be more easily like...? The break task is interesting. I am concerned however about how third party task containers would work with it. If the third-party container would like to support the break task, they would need to catch BreakException and handle it in the place where they iterate over their nested tasks and execute them. BreakException extends from BuildException. It gets thrown by the break task if it decides that the condition to break is met. Inside Ant, we'd need to modify Target, Sequential, and Parallel at obvious places to support break Peter Cheers, Magesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The Wabbit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
Subject:Re: macrodef and local From: Wascally Wabbit wascallywabbit () earthling ! net Why would BreakException subclass from BuildException? It's a Point taken. So long as it is some sort of RuntimeException, it is good enough. Also as a developer responsible for lots of task container code, I'm not thrilled with the idea of having to add this hook into every single task... Maybe we can code up some utility method like so: TaskContainerUtils.executeTaskList(TaskList, boolean isSequential) If your code uses this method instead of iterating through tasks and executing by itself, then we can achieve the break functionality without your container task having to bother about catching BreakExceptions. Anyway, all these are implementation details and I'd be happy to discuss them all if break is accepted as a need on a theoretical basis. Cheers, Magesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
--- Magesh Umasankar [EMAIL PROTECTED] wrote: From: Peter Reilly peter.reilly () corvil ! com Date: 2004-06-23 16:23:48 are some cases where true local properties would be more easily like...? like anytime you have to make two passes at some data to get a property set exactly the way you want it. Or you want to pass some data, formatted just so, to a task... MANY TIMES, like for each file in a fileset. Yes, you could write a Java task, or even a scriptdef, but one of the nicest things about macrodef is that anyone familiar with Ant can use it to build more complex behavior out of existing tasks. This could encourage task developers to keep the operations of their tasks as atomic as possible and increase the chance of reusability of pieces. I'm sure I don't need to illustrate the ease-of-use of macrodef vs. using Ant task classes from custom task code? So no, having local variables does not give us anything we can't do, but it does save us having to pollute the Project properties with e.g. 500 useless properties. The break task is interesting. I am concerned however about how third party task containers would work with it. If the third-party container would like to support the break task, they would need to catch BreakException and handle it in the place where they iterate over their nested tasks and execute them. BreakException extends from BuildException. It gets thrown by the break task if it decides that the condition to break is met. What if the third-party container would NOT like to support the break task? This starts to change the intent of what a Task does, no? Inside Ant, we'd need to modify Target, Sequential, and Parallel at obvious places to support break Sounds like break is fail with ac:try. If we were going to include flow control, ac:if would require less support programming. Peter Cheers, Magesh -Matt __ Do you Yahoo!? New and Improved Yahoo! Mail - Send 10MB messages! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
--- Magesh Umasankar [EMAIL PROTECTED] wrote: From: Matt Benson gudnabrsam () yahoo ! com Date: 2004-06-23 15:02:54 I cringe at the thought of the number of unique properties that could be floating about resulting from this... Is the user community complaining? [SNIP] BTW, apparently the user community is indeed complaining... there are nine votes for http://issues.apache.org/bugzilla/show_bug.cgi?id=23942 -Matt __ Do you Yahoo!? New and Improved Yahoo! Mail - 100MB free storage! http://promotions.yahoo.com/new_mail - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
From: Matt Benson gudnabrsam () yahoo ! com Date: 2004-06-23 17:43:46 code? So no, having local variables does not give us anything we can't do, but it does save us having to That is what I was trying to ensure. pollute the Project properties with e.g. 500 useless properties. -0. I don't think the above is a big concern of mine. What if the third-party container would NOT like to support the break task? They wouldn't delegate task execution to TaskContainerUtils.executeTaskList This starts to change the intent of what a Task does, no? No. The task does what it does when it is invoked. The container decides if the task is to be invoked at all. And it is eventually the user who decides that a break is needed and not Ant or any of the task containers. Cheers, Magesh - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
Jose Alberto Fernandez wrote:
The way I see it, a macrodef let will also solve the issue
of concurrency. Notice that in all this cases the issue is
how do you refer to the value just generated. Lets assume you
have the macro I defined before:
macrodef name=example
attribute name=foo/
let name=basefoo/
sequential
basename property=@{basefoo} file=@{foo}/
echo massage=[EMAIL PROTECTED]/
/sequential
/macrodef
Of course what this is really all about is the design decision for rigid
declarative syntax
in which there is no such thing as a function which returns a string into a
scalar. In effect,
you with your local properties and I with my recursive parsing are struggling
to retrofit
functional programming into Ant without spooking the ideologues :-)
--
Jack J. Woehr # We have gone from the horse and buggy
Senior Consultant # to the moon rocket in one lifetime, but
Purematrix, Inc. # there has not been a corresponding moral
www.purematrix.com # growth in mankind. - Dwight D. Eisenhower
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Jack J. Woehr [mailto:[EMAIL PROTECTED]
Jose Alberto Fernandez wrote:
The way I see it, a macrodef let will also solve the issue of
concurrency. Notice that in all this cases the issue is how do you
refer to the value just generated. Lets assume you have the macro I
defined before:
macrodef name=example
attribute name=foo/
let name=basefoo/
sequential
basename property=@{basefoo} file=@{foo}/
echo massage=[EMAIL PROTECTED]/
/sequential
/macrodef
Of course what this is really all about is the design
decision for rigid declarative syntax in which there is no
such thing as a function which returns a string into a
scalar. In effect, you with your local properties and I with
my recursive parsing are struggling to retrofit functional
programming into Ant without spooking the ideologues :-)
As the chief ideologue of the declarative camp that puts me in the spot
:-)
Lets not forget that real functional languages ARE declarative.
I.e.: variable names represent a value at the point they were defined
and you cannot change that value.
What ALL proper declarative languages have that ANT does not is
the concept of local variable (functional let X; prolog's X; lisp's
lambda x)
whose scope is just the local context in which they are mentioned.
Now that we can write recursion (the basic means of computation in any
declarative language) we see the need for such a thing.
But it is not an easy change for ANT because the tasks that manipulate
properties assume they are global. My attempt was to comply with their
assumption and provide them with a global name for them to use.
It is probably not the best solution, but I really fear about the impack
of some of the other proposals on the assumptions that ours and third
party tasks make of how things work.
My macrodef.let tries to provide a syntax for such a local variable
name.
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
There is a patch in
http://issues.apache.org/bugzilla/show_bug.cgi?id=23942
It provides general purpose scoped local properties and it is thread safe.
Part of the discussion on the patch was:
http://marc.theaimsgroup.com/?l=ant-devm=106916954118249w=2
Local properties may be declared in any block - a target, sequential or
macrodef.
There was a large discussion about the time of the first ant 1.6.0 beta,
where
I proposed using local properties for macro-def properties, but
luckilly, this
was rejected in favour of the more macro like attributes with the @{}
syntax.
When macrodef was first introduced, I was convinced that it was unusable
without
local properties. With the help of ant-contrib's propertyregex with
override=yes
one can do most of what local properties allow.
Peter
Wascally Wabbit wrote:
You can mostly kindof do this now by extending the PropertyHelper
class and
installing an instance in the ant.PropertyHelper reference. I've done
this
with two tasks isolate and overlay and both seem to work for most
issues
with scoped property modifications (inside macros or not).
While you wait for Ant 1.6.3 or 1.7(?), you might look at tweaking this
class...assuming such a feature gets add to the core source...
At 05:27 AM 6/17/2004, you wrote:
I am now convinced we need local properties; without it macrodef
doesnt work fully.
One option: in the macrodef declaration, you declare which
properties are local. When the macro exits these properties are
deleted -if they were not set before entering the macro.
That is, properties set before the macro remain immutable, only those
set inside get reset.
We'd need to do the cleanup on both a normal exit and a buildexception.
-steve
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
The Wabbit
-
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: macrodef and local
On Thu, 17 Jun 2004, Steve Loughran [EMAIL PROTECTED] wrote: I am now convinced we need local properties; without it macrodef doesnt work fully. I could agree with is less useful than it could be 8-) One option: in the macrodef declaration, you declare which properties are local. Peter's original patch went beyond that, it introduced scoped properties on all the block building levels. Restricting local properties to the macrodef task and not allowing any other task to use the same mechanism feels wrong to me. Once we decided that macrodef shouldn't use properties for attributes at all, the topic of scoped properties became less pressing. The discussion was tabled and here we are. IIRC (but my memory is failing quite a bit lately) the main unresolved discussion items have been * whether we want to add a new block type that forces you to list the scoped properties: macrodef sequential let property/ property/ ... yet-another-container actual-task1/ actual-task2/ ... /yet-another-container /let /sequential /macrodef vs. macrodef sequential local-property/ local-property/ ... actual-task1/ actual-task2/ ... /sequential /macrodef * shadowing: Is a local property allowed to have the same name as an existing plain old property and override the global value at all? * scoping rules for ant and friends: Are local properties visible to the build being invoked in something like macrodef sequential .. set up local properties .. ant file=some-other-file/ /sequential /macrodef i.e. do we choose lexical (they are not visible) or dynamic (they are visible) scoping? Peter and Jose Alberto, did I miss a point? Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Stefan Bodewig [mailto:[EMAIL PROTECTED]
On Mon, 21 Jun 2004, Jose Alberto Fernandez
[EMAIL PROTECTED] wrote:
basically, I think we need to decide (by taking into account the
consequences) if this local properties ARE properties or
are something
else that look like properties.
Unless we want to change all property setting tasks, they
have to be real properties IMHO. The main limitation I see
without local properties in macrodef is when your macro
uses a property setting task like basename or available -
you currently need to provide a unique property name to those
tasks if you want to reuse the macro.
Is this really the only reason, currently, for local properties?
Because if that is the case, maybe we can solve the problem in a
completely different way, which is specific to macrodef/.
For example, we could have a new kind of @{thing} whose value
is not passed as an attribute but guaranteed to be unique on the live
of the JVM. So a macrodef can generate as many new names as are required
and the programmer refers to them by local @{names}. E.g.:
macrodef name=example
attribute name=foo/
let name=basefoo/
sequential
basename property=@{basefoo} file=@{foo}/
echo massage=[EMAIL PROTECTED]/
/sequential
/macrodef
By making sure that let/ produces new names across the JVM from a
well known name-space, we can solve the problem, although poluting
the set of properties available during the build.
But everything will be just as it is today and there is no need for any
new feature of ANTCore, just of macrodef/.
What do people think?
Jose Alberto
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
I will go through what the patch does: * whether we want to add a new block type that forces you to list the scoped properties: The patch does not have a new block type. A new task - local/ has been added. local name=x/ defines a local property 'x' in the current block (target, sequential) which is in the un-set state. local name=x value=a value/ defines a local property 'x' which is set to a value * shadowing: Is a local property allowed to have the same name as an existing plain old property and override the global value at all? The patch allows local properties to shadow an existing plain property, unless that property is a user property. * scoping rules for ant and friends: Are local properties visible to the build being invoked in something like The patch has dynamic scoping of properties, so they will be seen by ant and friends if ant has inheritall set to true. Peter Stefan Bodewig wrote: On Thu, 17 Jun 2004, Steve Loughran [EMAIL PROTECTED] wrote: I am now convinced we need local properties; without it macrodef doesnt work fully. I could agree with is less useful than it could be 8-) One option: in the macrodef declaration, you declare which properties are local. Peter's original patch went beyond that, it introduced scoped properties on all the block building levels. Restricting local properties to the macrodef task and not allowing any other task to use the same mechanism feels wrong to me. Once we decided that macrodef shouldn't use properties for attributes at all, the topic of scoped properties became less pressing. The discussion was tabled and here we are. IIRC (but my memory is failing quite a bit lately) the main unresolved discussion items have been * whether we want to add a new block type that forces you to list the scoped properties: macrodef sequential let property/ property/ ... yet-another-container actual-task1/ actual-task2/ ... /yet-another-container /let /sequential /macrodef vs. macrodef sequential local-property/ local-property/ ... actual-task1/ actual-task2/ ... /sequential /macrodef * shadowing: Is a local property allowed to have the same name as an existing plain old property and override the global value at all? * scoping rules for ant and friends: Are local properties visible to the build being invoked in something like macrodef sequential .. set up local properties .. ant file=some-other-file/ /sequential /macrodef i.e. do we choose lexical (they are not visible) or dynamic (they are visible) scoping? Peter and Jose Alberto, did I miss a point? Stefan - 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: macrodef and local
On Mon, 21 Jun 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] The main limitation I see without local properties in macrodef is when your macro uses a property setting task like basename or available - you currently need to provide a unique property name to those tasks if you want to reuse the macro. Is this really the only reason, currently, for local properties? Not the only, but a very important one. Because if that is the case, maybe we can solve the problem in a completely different way, which is specific to macrodef/. What you describe is pretty much what I (and probably anybody else) use as a workaround. I create what would be a local property by using a name contains the name of at least one of the task's attributes. I don't think I'd like to turn this into a formalized solution with the property namespace polution you get. Also, you can't guarantee unique property names since you don't know which normal Ant property names will be used later in the build - outside of macrodefs. All you could guarantee is that the name hasn't been used yet and won't clash with a name a let construct would create later. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: macrodef and local
From: Stefan Bodewig [mailto:[EMAIL PROTECTED] Because if that is the case, maybe we can solve the problem in a completely different way, which is specific to macrodef/. What you describe is pretty much what I (and probably anybody else) use as a workaround. I create what would be a local property by using a name contains the name of at least one of the task's attributes. I don't think I'd like to turn this into a formalized solution with the property namespace polution you get. Also, you can't guarantee unique property names since you don't know which normal Ant property names will be used later in the build - outside of macrodefs. All you could guarantee is that the name hasn't been used yet and won't clash with a name a let construct would create later. True, but I doubt many people will use properties called for example: #ant.task.macrodef.example.let1 #ant.task.macrodef.example.let2 #ant.task.macrodef.example.let3 #ant.task.macrodef.example.let4 Or some silly name space like that. My problem with the real local properties is that I think they will require a lot of work and thought before we can have something really rubust. If, as we have done in the past, put out there something that we have not really considered all the concequences properly, we will finish with all sorts of backward compatibility issues when we find the drawbacks (or the users find them). It would not be the first time this happens so I am talking based on the historical experience. The payoff of general local properties seems quite limited, as far as I can see. Have you found any compelling usage for them on their own? ant co. already provide stack (but is expensive). Whatever we do in this regard, we probably need to provide for references also. But he, I just though about this for 30secs before proposing it, so shoot at it if you think is not worth the electrons is written on :-) Jose Alberto - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
On Mon, 21 Jun 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: True, but I doubt many people will use properties called for example: #ant.task.macrodef.example.let1 8-) What if they do? Hypothetical, I know. Still we'd be carying them around (and passing them down to subbuilds with inheritall=true). My problem with the real local properties is that I think they will require a lot of work and thought before we can have something really rubust. Quite possible. If, as we have done in the past, put out there something that we have not really considered all the concequences properly, we will finish with all sorts of backward compatibility issues when we find the drawbacks (or the users find them). It would not be the first time this happens Of course not. The payoff of general local properties seems quite limited, as far as I can see. Have you found any compelling usage for them on their own? No, *I* haven't. Others may have. Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
Stefan Bodewig wrote: On Mon, 21 Jun 2004, Jose Alberto Fernandez [EMAIL PROTECTED] wrote: From: Stefan Bodewig [mailto:[EMAIL PROTECTED] The main limitation I see without local properties in macrodef is when your macro uses a property setting task like basename or available - you currently need to provide a unique property name to those tasks if you want to reuse the macro. Is this really the only reason, currently, for local properties? Not the only, but a very important one. Because if that is the case, maybe we can solve the problem in a completely different way, which is specific to macrodef/. What you describe is pretty much what I (and probably anybody else) use as a workaround. I create what would be a local property by using a name contains the name of at least one of the task's attributes. It seems to me that if someone really needs this sort of thing, then the use of Ant-Contrib's Variable is pretty much sufficient, esp. if property parsing becomes recursive (e.g., per the patch I submitted already) so that you can access properties via a second-level indirection. Would one then still need locals? If absolutely necessary, a GenUniquePropertyName task could be coded. -- Jack J. Woehr # We have gone from the horse and buggy Senior Consultant # to the moon rocket in one lifetime, but Purematrix, Inc. # there has not been a corresponding moral www.purematrix.com # growth in mankind. - Dwight D. Eisenhower - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
You can mostly kindof do this now by extending the PropertyHelper class and installing an instance in the ant.PropertyHelper reference. I've done this with two tasks isolate and overlay and both seem to work for most issues with scoped property modifications (inside macros or not). While you wait for Ant 1.6.3 or 1.7(?), you might look at tweaking this class...assuming such a feature gets add to the core source... At 05:27 AM 6/17/2004, you wrote: I am now convinced we need local properties; without it macrodef doesnt work fully. One option: in the macrodef declaration, you declare which properties are local. When the macro exits these properties are deleted -if they were not set before entering the macro. That is, properties set before the macro remain immutable, only those set inside get reset. We'd need to do the cleanup on both a normal exit and a buildexception. -steve - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The Wabbit - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: macrodef and local
I am still hoping we will have a multi-threaded ANT some time. Please implement local properties in a thread-safe way. I think a separate thread-local property store would be required for that. - Alexey. Steve Loughran wrote: I am now convinced we need local properties; without it macrodef doesnt work fully. One option: in the macrodef declaration, you declare which properties are local. When the macro exits these properties are deleted -if they were not set before entering the macro. That is, properties set before the macro remain immutable, only those set inside get reset. We'd need to do the cleanup on both a normal exit and a buildexception. -steve - 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]
