> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > > > To me <let> is the correct solution that may need to get > extended to > > cover additional cases. Your task that generates unique names has > > merits of its own and independent of that. Your (much simpler) > > approach would need an additional cleanup mode to get rid of my > > concerns and you are already willing to provide that. > > I have two remarks to this long and somewhat controversial thread: > > 1) I don't like the <let> name. Perhaps it shows how ignorant I am > about other languages not in the C family, but it doesn't speak > to me, and the name to not convey the purpose. Thus I'm -1 to > the <let> name. <scope> or <local> or else are not perfect, but > at least convey more meaning to my ignorant self. >
:-(. <let> comes from mathematics. "Let X be a ...." so it just provides a name that we can use to refer to something. It is not a location or a value it is just a name (actually $(X) is just a name). That is the reason for using <let>, it is also used in some functonal languages. The scope, is the scope of the attribute notation (i.e., the macrodef). Now you can use this name to create a new property, using <property/> or to watever else you please, there are no expectation whatsoever. > 2) Regarding property cleanup, we already have a datatype and syntax > to specify/select properties. It's called <propertyset>, and it > does handle property selection by name/prefix/regexp. So I'd just > change Peter's proposal have having a <localproperty> inside > <macrodef> with a <localproperties> which would be a PropertySet. > > The property set can be evaluated before and after the macro > execution to record before and restore/remove properties after. > And I have mentioned several times that one could use propertysets to stop things leaking through <antcalls> and such. But you are still thinking only on properties. There are other things that we create dynamically in ANT. Like references, scripts, etc. > Finally, as Jack J. proposed, what is it exactly that > prevents us from retrofitting a real property/reference stack > in Project? Jose Alberto said he proposed it in the past, and > it got nowhere, but now that we have Peter, maybe we should > revisit ;-) > > My currently limited understanding of property/reference > handling in Ant does not allow me to see any insurmountable > issue. Can we in fact revisit this subject, since local > properties pretty much would be solved with a real stack. Or > am I just naïve, and a real stack is not possible to > implement in a backward compatible manner? --DD > The main hurdle is that ANT uses a flat namespace for things and that anypart can see any property/reference defined by any other part at any time on the life of the project. This changes between antcalls and such. Not only one can do it, but it is the basis of how ANT works, with its "if/unless" attribute, for example. To change everything to now work using scopping rules. Is like trying like changing Fortran-62 to work like Algol-66 but maintaining backward compatibility. I know they are very old concepts here, but just as old are the data structures we used in ANT. And on top, the fact that something does not exist is meaningful (i.e., unless) I do not see how you can reconcile all this things. Maybe this should be done as part of ANT 2.0 (joke). And forget about BC, 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]
