ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject RE: Ant 1.6 local and macrodef attributes
Date Sat, 29 Nov 2003 00:39:13 GMT

Thanks for explaining that Peter.

I took a look and found your latest proposal here...
http://marc.theaimsgroup.com/?l=ant-dev&m=106993855725136&w=2

Seems that Stefan liked it...
http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2

So, I guess that means that proposal #1 below is going to be implemented 
for Ant-1.6.  However, does this still leave <local> properties out to 
dry?  I'm totally fine with using @{x} syntax for attributes, but macrodef 
is still mostly useless to me unless I can do...

<macrodef name="A">
     <attribute name="test.file"/>
     <sequential>
        <local name="file.available"/> <!-- this is the part that makes 
this macrodef non-useless. -->
        <available property="file.available" value = "yes" 
file="@{test.file}"/>
        <property name="file.available" value="no"/>
        <echo>Is @{test.file} available? ${file.available}.</echo>
     </sequential>
</macrodef>


Jake

At 06:33 PM 11/27/2003 +0000, you wrote:
>Hi Jacob,
>Most of this discussion is on the dev listing.
>I can understand your confusion.
>
>A brief history.
>(You can search with keyword local at
>http://marc.theaimsgroup.com/?l=ant-dev&r=1&w=2
>to get the full gory details)
>
>When macrodef was written originally, attributes
>were (and are) implemented as textual substitution.
>This was ok but they looked like normal properties
>(using the ${x} notation). This caused a lot of
>debate/confusion but I resisted changing the notation as I
>do not like using different notation.
>
>After using macrodefs for a little while I and other
>people became aware that ant uses properties for
>passing information between tasks and only having
>non-mutable properties reduce the usefulness of
>macrodefs a lot.
>
>One can use ant-contrib's propertyregex and (via antelope)
>var, and just overwrite properties - but this felt
>like a big hack.
>
>So one week-end I said what the heck and attempted to
>implement local properties. It when through a number
>of iterations.
>
>When this was done, I realized that attributes could
>be implemented by local properties and the problems
>with notation would go away.
>
>This interpretation of reality was not (to say the
>least) universally accepted.
>
>After the 1000'th e-mail explaining what was wrong
>with this, I realized that there may be a point
>in the argument.
>
>So now there is two proposals:
>
>1) to change the macrodef attribute notation from ${x}
>    to @{x}.
>
>2) add local properties - completely independent from
>    macros - but can be used by them. (This is basically
>    what the patch implements but without the @{x} notation)
>
>The problem is that as these are serious changes to
>ant internally (in the case of local) and externally
>(new notation for attributes, properties seem not be non-mutable,
>syntax of local), the changes need support from the ant committers.
>
>As the local stuff is so new some would like to exercise it a
>bit is 1.7 before committing to supporting for all time the
>particular implementation and its public interfaces.
>
>Peter
>
>On Thu, 2003-11-27 at 17:50, Jacob Kjome wrote:
> > At 07:03 AM 11/27/2003 -0600, you wrote:
> > >The problem with this is that the property "file.available" cannot be
> > >redefined a second time now because the macrodef lives outside of any 
> target
> > >and so this property resides on top level.
> > >
> > >Is this essentially the problem you are facing?
> >
> > That is exactly the problem I am facing.
> >
> > >My answer would be that I am not opposing the use of <local> properties
> > >inside of macrodef calls anyway.  All that I am opposed to is 
> implementing
> > >the <attribute> functionality with the same <local> mechanism.
> >
> > I always assumed that the attributes were local only to the macrodef
> > anyway.  I must have missed a bunch of the developer conversation.  What
> > purpose would <local> serve to an attribute that is already only in local
> > scope?  As far as I can tell, the current patch doesn't make <attribute>'s
> > global.  What does <local> have to do with <attribute>'s????  Man, I
must
> > really be missing something here.
> >
> > >  test.file is an <attribute>.  It is not a property of any kind, 
> local or
> > > otherwise.  If you want to say that any actual properties, defined 
> within
> > > a call to a <macrodef>
> > >either by invoking a target or directly are local, as the 
> "file.available"
> > >property above, this garners no opposition from me.
> >
> > Well, that's a relief.  So, I guess I don't understand what all the
> > opposition is about then?  Can't we add <local> so that It works for tasks
> > that return actual properties and leave it at that?  You macrodef would
> > look like this...
> >
> > <macrodef name="A">
> >     <attribute name="test.file"/>
> >     <sequential>
> >        <local name="file.available"/> <!-- this is the part that makes

> this
> > macrodef non-useless. -->
> >        <available property="file.available" value = "yes" 
> file="@{test.file}"/>
> >        <property name="file.available" value="no"/>
> >        <echo>Is @{test.file} available? ${file.available}.</echo>
> >     </sequential>
> > </macrodef>
> > ...
> > <A test.file="foo.bar"/>
> > ...
> > <A test.file="bar.food"/>
> >
> >
> > I'm also not clear on the @{test.file} syntax.  I'm using ${test.file} and
> > it works just fine.  Actually, I just tried it and the @ syntax doesn't
> > currently work (having applied the <local> patch).  Is this what all the
> > hubbub is about?  If you are saying that you'd approve of the local patch
> > if it changed the syntax for accessing <attribute>'s to @{attribute.name}
> > from ${attribute.name}, then lets do it!  I don't care what the syntax is
> > for accessing <attribute>'s as long as I can use <local
> > name="someproperty"/> to keep  the property (not attribute, mind you)
> > "someproperty" resettable upon the next call to the same macrodef rather
> > than being set globally and, therefore, permanently the first time the
> > macrodef is called.  Like I've said before, without this functionality, 
> the
> > above macrodef is totally useless.
> >
> > Is this doable or is there some technical issue standing in the way?
> >
> > Jake
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
> > For additional commands, e-mail: user-help@ant.apache.org
> >
> >
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@ant.apache.org
>For additional commands, e-mail: user-help@ant.apache.org


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


Mime
View raw message