> From: Steve Loughran [mailto:[EMAIL PROTECTED] > > Antoine Levy-Lambert wrote: > > So far, I have got two +1 (myself and Jan Materne) for this > proposal. > > The vote will be closed tomorrow at 12:28 pm CET (20 hours > from now). > > Three +1s are required for a code change, so, by the likes > of it, the > > vote will have a negative result. > > > > The <antfetch/>, <antcallback/>, <call/> tasks of Antelope provide > > functionality in terms of returning properties. This > <antreturn/> is > > also returning references, so it can bring something new, plus the > > ease for users who want to deploy ant, but no extra jars providing > > core functionality to ant. > > > > Since there are already tons of changes in ant 1.6 alpha, > there can be > > some wisdom in refusing or postponing this change. > > > I'm kind of neutral on the idea. I can see it has its uses, > but can also > see it as kind of dangerous. It is nowhere near as controlled > a return > mechanism as, say, a method call where unless global variables are > changed, the return parameters get stuck in properties of the callers > choice, not the callees. >
I have to say that I do have uses for this kind of thing, but I agree that the implementation of this feature should give control to the caller on the naming of the properties being returned. A suggestion on that regard would be adding a "prefix" attribute to <antreturn/> so that the properties get set on a separate "namespace" and after that the caller can copy the values around as they see fit. Alternatively, each individual property being returned should have a "property" or "reference" attribute to indicate the location in which to put it. I think the "prefix" solution is less intrusive and we have used it before when reading properties from the environment. As per cases when you need this, I have today a large buildfile that deals with things like managing CVS operations, one of the things that it knows how to do is to identify the current-branch one is working on. Now this is a large file and I really do not want to mix it (import) with the buildfile for compiling the code. However, when we build a binary deliverable I would like to include information about the current-branch and such. I do not want to have multiple versions of the code, I would prefer being able to obtain this information by simply doing an <antreturn> or something like that. It is much more cleaner than <importing> and giving access in the build file to a bunch of things that where not intended. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
