From: "Peter Donald" <[EMAIL PROTECTED]> > 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. I really do not care about this names, but I have never heard the term Workspace used for a calling stack. Can you expand on your reasons?
> > > 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. > Well, if you look at some ot the other proposals for scoping rules, you see two things floatings around: mutability and global properties. Both are there as a way for people to do something in an <ant> call and obtain results by global side effects. Now, if there is an actual need for being able to retrieve information from subordinate build processes <returns> is much more modular than global variables. > > 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. Oh that sounds like the flexibility syndrome sneaking on you. :-) Jose Alberto
