On Sat, 20 Oct 2001 19:36, Jose Alberto Fernandez wrote: > 3) Invocation scope: what we have called user-properties in the past. > Implemented by <param> on <ant*>. The value takes precedence from > any definitions in the project being called (just like ANT1). > Parameters in command line follow the same rules.
I would call this Workspace scope. > Finally, there is the issue of how to get values back from an invocation. > How can that be worked out without violating either modularity or > inmutability? I have been thinking on a form of return-values for <ant*> > calls. The idea is something like: Treating <ant> as a function with return statements has been -1'ed so many times I can't see this flying. > All tasks that define something (<property>, <type>, <available>, etc. Will > act on a current scope provided by the container. The scoping and > overriding rules will be enforced by ANT ant not the individual tasks as it > is today. Thats an interesting question. Should the container or the task implement policy? Container implementing it is useful because that means it has complete control over it and tasks always behave consistently. The disadvantage being that you may sometimes want inconsistencies. -- Cheers, Pete *---------------------------------------------------------* | Contrary to popular belief, UNIX is user-friendly. It | | just happens to be selective on who it makes friendship | | with. | | - Richard Cook | *---------------------------------------------------------*
