ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <jalbe...@cellectivity.com>
Subject RE: <local> for 1.6
Date Fri, 24 Oct 2003 13:18:06 GMT
> From: peter reilly [mailto:peter.reilly@corvil.com] 
> 
> 
> On Friday 24 October 2003 12:25, Stefan Bodewig wrote:
> > Back to the original start.
> >
> > Peter, now that you are convincing yourself that <macrodef> 
> attributes 
> > shouldn't create <local>s - is there still a backwards 
> incompatibility 
> > to be expected once <local>s get introduced?  Or have we reached a 
> > point where <macrodef>'s behavior is independent of <local>?
> 
> No.
> 
> Either attributes are seen as properties by the contained
> tasks or there is a textual substitution by the 
> macrodefinition. There is a differnce in behaviour.
> 
> Allowing the attributes be seen as normal properties by
> the contained tasks is most likely a good thing.
> 

I disagree, if what we have has any resemblance with the meaning
of the work macro, its parameters (i.e., atributes) should be textually
substituted in the macrodefinition. That is what happens in every
macro language I know of. Why should we be any different.

Trying to use locals for macrodefs attributes the only thing it does
is make locals even more complex than they should be.
    
> 
> >
> > If the later is the case, I'd suggest we rediscuss the 
> local feature 
> > for the 1.7 timeframe and do not put it into 1.6.
> 
> Another solution would be to get <macrodef> to use the local 
> property mechanism do the other parts of the implementation 
> in 1.7 (or 1.6.1). So the <local/> task and the mods to 
> target and  unknownelement to support <local/> could be left to 1.7.
> 

I disagree with this. What we were calling locals was a feature not for
macrodef but for other purposes. This only means we will need to come
with a
completely different task for what we were calling <local> that is
independent
of the <macrodef> requirements.

Jose Alberto
> Peter
> >
> > Stefan
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> > For additional commands, e-mail: dev-help@ant.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
> For additional commands, e-mail: dev-help@ant.apache.org
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message