> From: Jose Alberto Fernandez [mailto:[EMAIL PROTECTED] > > From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > From: Stefan Bodewig [mailto:[EMAIL PROTECTED] > > 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.
Maybe in your part of the world... > That is the reason for using <let>, it is also used in some functonal > languages. I though so. I'm still -1, or at best -0 if I hear more convincing arguments. > 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. I'm not following. I think I understand what a scope is. I don't confuse scope for the notation to define explicitly what should 'go out of scope' when the explicit scope ends. I consider running a <macrodef> as starting/entering a new scope for names, doing something, then ending/leaving the scope, restoring shadowed properties and removing local properties, as defined by the propertyset. > 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. Not at all. I'm thinking properties and references. What else is there? Scripts are scripts, id'd or not. That's still references. > 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. So? As Peter points out, a flat namespace doesn't mean it cannot be implemented using a stack of maps per scope, similar the nesting of Properties when you provide a default. It's still flat, but uses nested Properties to provide correct compartimentation. This is how <antcall> should have been implemented instead of the copy going on right now. > 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, Sorry, but I still don't see why it can't be made BC... The Project API has to be unchanged of course, but the actual impl should move to a lighter weight Context object or something that would be stacked correctly, and to which Project would delegate to. Dealing with <parallel> would be tricky, but I think we *should* break BC by not allowing the different 'threads' of a <parallel> to share properties, at least unless explicitly requested. But that's going into too much detail for now. --DD --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
