Hi Peter,
I have been quite silent recently because I am busy at work ...
I am OK for the @{attributename} syntax for the textual substitution of
attributes in macrodef.
Cheers,
Antoine
-----Ursprüngliche Nachricht-----
Von: Peter Reilly [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 1. Dezember 2003 09:59
An: Ant Developers List
Cc: Steve Cohen; [EMAIL PROTECTED]
Betreff: Re: Ant 1.6 local and macrodef attributes
The work-around [EMAIL PROTECTED] will work.
<macrodef name="d">
<attribute name="prop.name"/>
<sequential>
<echo>prop.name is @{prop.name} prop value is
'[EMAIL PROTECTED]'</echo>
</sequential>
</macrodef>
<property name="prop" value="This is the value of prop"/>
<d prop.name="prop"/>
results in:
[echo] prop.name is prop prop value is 'This is the value of prop'
The @{} update has not been applied yet - still waiting for positive
feedback from ant committers.
Peter
Jacob Kjome wrote:
>
> Thanks for that Steve. I really appreciate you going the extra mile
> to help out with a solution to this predicament. If your example
> below actually works with Ant-1.6 final then, ugly or not, I'll be
> satisfied with the temporary solution and will patiently wait for a
> less hacky solution in Ant-1.7.
>
> Can anyone verify that Steve's work around actually works? When will
> the @{x} stuff be committed to the 1.6 branch (or is it already)? I'd
> like to test it out ASAP.
>
> Jake
>
> At 10:20 AM 11/29/2003 -0600, Steve Cohen wrote:
>
>> <moving this discussion to ant dev list and including Jacob Kjome>
>>
>> Thanks, Jacob, for continuing to pursue this, and deepening my
>> awareness of the problem.
>>
>> I appreciate your dilemma, even though I still agree with what has
>> become consensus that textual substitution is right for <macrodef>.
>> The whole business with the scope of properties is already
>> complicated enough. The <local> patch or something like it will be
>> necessary to solve your use case. But is <local> the right thing?
>> Maybe we need to think more generally (not, heaven forbid, for
>> 1.6!!!) about tasks that return values in properties and how these
>> should be implemented in the context of macrodefs.
>>
>> The key point is that when such a property was called inside of an
>> antcall that created a property locally within the execution context
>> of the <antcall> call. Textual substitution destroys that. A
>> <macrodef> looks like a separate execution context but is not, at
>> least not as currently set up.
>>
>> Since that is unlikely to be resolved in time for 1.6, can we suggest
>> a workaround for the interim?
>>
>> I think we can. It's a bit ugly, but it does allow us to replace
>> macrodefs calling tasks that return properties, even without
>> <local>. We just add one level of indirection.
>>
>> Instead of this:
>>
>> <macrodef name="A">
>> <attribute name="test.file"/>
>> <sequential>
>> <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"/>
>>
>> where the problem is that the property "file.available" cannot be
>> redefined a second time now because the macrodef lives outside of any
>> target and this property therefore resides on top level
>>
>> we can instead do this:
>>
>> <macrodef name="A2">
>> <attribute name="test.file"/>
>> <attribute name="available.prop"/>
>> <sequential>
>> <available property="@{available.prop}"
>> value = "yes"
>> file="@{test.file}"/>
>> <property name="@{available.prop}" value="no"/>
>> <echo>Is @{test.file} available? [EMAIL PROTECTED]</echo>
>> </sequential>
>> </macrodef>
>> ...
>> <A2 test.file="foo.bar" available.prop="foo.bar.available"/>
>> ...
>> <A2 test.file="bar.food" available.prop="peanuts.available"/>
>>
>> This is annoyingly less simple than <local> but still allows
>> <macrodef> to be used in 1.6 with tasks that return values in
>> properties. I am assuming that
>> [EMAIL PROTECTED] would be handled correctly by textual
>> expansion. Someone please correct me if I'm wrong.
>>
>>
>>
>>
>> -----Original Message-----
>> From: Jacob Kjome [<mailto:[EMAIL PROTECTED]>mailto:[EMAIL PROTECTED]
>> Sent: Fri 11/28/2003 6:39 PM
>> To: Ant Users List
>> Cc:
>> Subject: RE: Ant 1.6 local and macrodef attributes
>>
>> 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>http://marc.t
heaimsgroup.com/?l=ant-dev&m=106993855725136&w=2
>>
>>
>> Seems that Stefan liked it...
>>
<http://marc.theaimsgroup.com/?l=ant-dev&m=106994393230831&w=2>http://marc.t
heaimsgroup.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>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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
