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: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
