> From: Dominique Devienne [mailto:[EMAIL PROTECTED] > > > 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... >
Well the last I checked, in english, when you write a definition, or a proof, or a theorem, or whatever. You ussually start with something like: "Let G(V,E) be a graph, and let X be a person trying to understand the concept of a graph. The ability of X to understand what G means is ...." :-) Now, X is just a moniker, it is not a person. In my next definition X may stand for something else. Very simillar to what <let/> does. Now, maybe in a different language you use a different construction. But that is not the point, is it. In any case, the argument is about the concept of defining a name and not a location. > > 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. > Do not confuse "names" with "namespaces". Names may be flat, but if you have a stack of maps, you definetly do not have a flat namespace. Same applies for "C", and does not applies for Fortran. > > 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. > As long as you do not change the meaning or behavior of <tasks/> INCLUDING third party tasks that we cannot go and change. We have a contract with people writing tasks. If we want to break it we should move to ANT 2.0 and have to development lines. > 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. > So what do you do about <waitfor/> ? It is there for a reason. > But that's going into too much detail for now. --DD The details is what is important here. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
