ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: local properties
Date Wed, 20 Oct 2004 17:09:11 GMT
> From: Dominique Devienne [] 
> > From: Jose Alberto Fernandez []
> > > From: Dominique Devienne []
> > > > From: Stefan Bodewig []
> > > 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,
> > >    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

 "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:
For additional commands, e-mail:

View raw message