 | | | Target or macrodef? | Target or macrodef? 2004-08-25 - By peter reilly
Inger, Matthew wrote:
>I was trying to stay away from Ant Contrib in this discussion
>(even though I'm the project admin on it). The bottom line is
>that they way macros are implemented makes declaring properties
>inside of the macrodef very difficult, as it's hard to re-use the
>macros and/or the calling targets.
>
>It's something that ANT itself should handle. Perhaps either the
>stackable approach as i mentioned, or maybe another task like:
>
><local name="local.property" value="..." />
>
>Any "local" variables get cleaned when the macro finishes running.
>This should be a very easy approach to implement.
>
>
This is exactly the approach that the "local" patch takes.
The build snippet then becomes (after moving the available into the if
condition):
<for list="${rbfilelist}" delimiter=";" param="rbfile">
<sequential>
<local name="sourcefile"/>
<getsrcname listitem="@{rbfile}" property="sourcefile"/>
<if>
<available file="${PRODUCT}/${sourcefile}.str"
<then>
<property name="rbstrFilesAvailable" value="true"/>
<echo message="${PRODUCT}/${sourcefile}.str"/>
</then>
</if>
</sequential>
</for>
In this case the local property gets created in the "unset" state, so
<getsrcname/> can set
it.
The "sourcefile" property is local to the seqential block use - so a
different local property
will be used each time thu the for loop.
Outside the for loop the "sourcefile" will not be set (unless there is
already a "sourcefile" property).
Some of the issues with the patch were:
* what is the treatment of user properties - i.e. should local
properties not be allowed to have the same
name as user properties
* what is the scope of the local properties - should there be a special
block to delimit the
scope of the variables.
* the implementation is a little complex (uses threadlocal stacks)- it
perhaps could be less
* macrodef can be powerful without use of local varialbes - using the
constructed names idea for
semi-unique properties
* adding local properties makes the whole property mess^D rules more complex
* there is no local references
Peter
>-----Original Message-----
>From: Jeffrey Bacon [mailto:jbacon@(protected)]
>Sent: Wednesday, August 25, 2004 12:40 PM
>To: Ant Users List
>Subject: Re: Target or macrodef?
>
>
>you all know you can use the Ant Contrib libraries and get 'var' which
>is mutable properties eh? Doesn't that kinda make temp properties a
>moot point? I guess you are dependent on a library then.
>--
>Jeffrey Bacon
>jbacon@(protected)
>Creative Developer
>http://www.magmic.com
>
>
>Jacob Kjome wrote:
>
>
>>Well put! However...
>>
>>
>>
>>
>>>There is one drawback to this approach and that is that the target cannot
>>>
>>>
>be
>
>
>>>used again in the same process instance. If it is used again the temporary
>>>properties may cause a conflict because of their immutability if you try
>>>
>>>
>to
>
>
>>>change their value.
>>>
>>>
>>This is why it is, technically, a "hack". Keep in mind, I use the term in
>>
>>
>the
>
>
>>nicest way possible. That this works perfectly fine in 99% of the cases
>>
>>
>and
>
>
>>that I find it very useful, understandable, and maintainable, I think it
>>
>>
>is
>
>
>>perfectly legitimate. But the fact that there seems to be a need for
>>
>>
>temporary,
>
>
>>throw-away, properties means that Ant should, arguably, provide a
>>
>>
>construct for
>
>
>>this which serves this purpose exactly without side effects like those
>>
>>
>described
>
>
>>by your own comment.
>>
>>BTW, you can usually cut down on the possibility of dynamic property name
>>duplicates by using two or more macrodef attribute values to create the
>>
>>
>dynamic
>
>
>>property name. You'd have to set it up where any one attribute value
>>
>>
>might
>
>
>>occur more than once, but the chances of the combination happening more
>>
>>
>than
>
>
>>once is much less. You may not always have this opportunity, but
>>
>>
>depending on
>
>
>>the values coming in, you may be able to use them to your advantage.
>>
>>Jake
>>
>>
>>Quoting Bill Rich <billrich@(protected)>:
>>
>>
>>
>>
>>>I guess I must disagree with both of you to some degree. In this snippet
>>>
>>>
>>>from an Ant file that I use for process control (not a build process) I
>>
>>
>need
>
>
>>>a temporary property. I am not even sure I could do this with <antcall>
>>>
>>>
>but
>
>
>>>I would not want the overhead anyway.
>>>
>>>The background on this snippet is that I need a list of files in a file
>>>
>>>
>for
>
>
>>>use by a merge program. Here I make a temp prop (file.in.@{rbfile}) to
>>>
>>>
>hold
>
>
>>>the file name that I get from a list that has been loaded earlier in the
>>>process. I also use a temp prop (file.exists.@{rbfile}.str) to test to
>>>
>>>
>make
>
>
>>>sure the file was actually created before I put it in the temp file. (It
>>>
>>>
>is
>
>
>>>the nature of the process that some of these files may not be created and
>>>the merge program horks if the file is not available. A better solution to
>>>checking availability would be to fix the merge program so it tolerates
>>>missing files.)
>>>
>>>I disagree that this is a hack. It is nothing more than coding to the any
>>>language spec. Property immutability is a fact in ant and I accept that (I
>>>even agree with it). This is a case where I need to have a bunch of
>>>properties because of the type of processing I am doing. I am using ant
>>>
>>>
>for
>
>
>>>something it was not designed to do but it works. I don't consider this
>>>
>>>
>code
>
>
>>>any more difficult to maintain than any other code I have to work with.
>>>
>>>
>Most
>
>
>>>of the code I work with is not mine and sometimes has been coded to many
>>>different standards. That code is difficult to read and understand. This
>>>
>>>
>ant
>
>
>>>code is not that difficult.
>>>
>>>There is one drawback to this approach and that is that the target cannot
>>>
>>>
>be
>
>
>>>used again in the same process instance. If it is used again the temporary
>>>properties may cause a conflict because of their immutability if you try
>>>
>>>
>to
>
>
>>>change their value.
>>>
>>>Local properties may be a benefit in this and some other cases but I am
>>>
>>>
>not
>
>
>>>going to worry if they never get implemented. This works just fine.
>>>
>>><... snip ...>
>>><tempfile property="temp.rbstr.file" suffix=".txt"/>
>>><record name="${temp.rbstr.file}" emacsmode="true" action="start"/>
>>><for list="${rbfilelist}" delimiter=";" param="rbfile">
>>> <sequential>
>>> <getsrcname listitem="@{rbfile}" property="file.in.@{rbfile}"/>
>>> <available file="${PRODUCT}/${file.in.@{rbfile}}.str"
>>>property="file.exists.@{rbfile}.str" value="avail"/>
>>> <if>
>>> <equals arg1="${file.exists.@{rbfile}.str}" arg2="avail"/>
>>> <then>
>>> <property name="rbstrFilesAvailable" value="true"/>
>>> <echo message="${PRODUCT}/${file.in.@{rbfile}}.str"/>
>>> </then>
>>> </if>
>>> </sequential>
>>></for>
>>><record name="${temp.rbstr.file}" action="stop"/>
>>><... snip ...>
>>>
>>>Thanks. Bill
>>>
>>>Bill Rich
>>>Wilandra Consulting LLC
>>>1325 Addiewell Place
>>>San Jose, CA 95120-3905
>>>phone: +1 408 268-2452
>>>mobile: +1 408 410-9713
>>>Santa Cruz: +1 831 464-9007
>>>fax: +1 413 669-9716
>>>billrich@(protected) or billrich@(protected)
>>>http://www.wilandra.com
>>>
>>>-----Original Message-----
>>>From: Jacob Kjome [mailto:hoju@(protected)]
>>>Sent: Wednesday, August 25, 2004 6:55 AM
>>>To: Ant Users List
>>>Subject: Re: Target or macrodef?
>>>
>>>At 08:48 AM 8/25/2004 +0200, you wrote:
>>>
>>>
>>>
>>>>>>hi,
>>>>>>this would be great !
>>>>>>
>>>>>>recently, i had exactly that problem (setting a "temp" property in
>>>>>>a
>>>>>><macrodef/>) ... i had to use <antcall/> as work-around :(
>>>>>>
>>>>>>
>>>>>>
>>>>>Well, <antcall> is just totally unnecessary. Just use the value of
>>>>>the macrodef attributes as a property. Obviously it becomes a
>>>>>property that will live throughout the app, but it is usually so
>>>>>unique that that you'd never define or generate another property by
>>>>>the same name. If the value won't be unique, you can chain multiple
>>>>>macrodef attribute values together to make a truly unique property.
>>>>>For more information, see...
>>>>>
>>>>>http://ant.apache.org/faq.html#propertyvalue-as-name-for-property
>>>>>
>>>>>
>>>>i disagree - i guess there are of course reasons for using <antcall/>
>>>>and i guess my example above is one of them.
>>>>
>>>>while ur "solution" or better called "work-around" may work too i
>>>>would not use it cause THIS is an ugly hack - thats the way
>>>>unmaintainable code is produced! what u r talking about is "generating"
>>>>property names and this does definitively makes the code harder to read
>>>>... at least IMHO ... what does a generated property name tell about
>>>>its use or the coders intention ? nothing!
>>>>i guess the best and obious solution would be to allow some kind of
>>>>variable scoping in ant.
>>>>
>>>>
>>>I see your point and I already referred to it as a "hack", but I disagree
>>>that it is unmaintainable. Since the property is meant to be used
>>>temporarily, the confusion will only be in one place; the macrodef itself.
>>>I would suggest simply writing a comment saying what exactly is being
>>>
>>>
>done.
>
>
>>>Most macrodefs aren't tremendously large so a little documentation should
>>>suffice to ease or resolve any confusion that might otherwise occur. The
>>>bloat and messiness of <antcall> far outweighs any disadvantages of the
>>>current "hack" available in macrodef. Like I said before, a local
>>>
>>>
>property
>
>
>>>might be nice, but it won't bother me if it never makes it into Ant as the
>>>"hack" is all I need.
>>>
>>>Jake
>>>
>>>
>>>
>>>
>>>
>>>>thx
>>>>regards,
>>>>seb
>>>>
>>>><snip/>
>>>>
>>>>---------------------------------------------------------------------
>>>>To unsubscribe, e-mail: user-unsubscribe@(protected) For additional
>>>>commands, e-mail: user-help@(protected)
>>>>
>>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@(protected) For additional
>>>commands, e-mail: user-help@(protected)
>>>
>>>
>>>
>>>
>>>---------------------------------------------------------------------
>>>To unsubscribe, e-mail: user-unsubscribe@(protected)
>>>For additional commands, e-mail: user-help@(protected)
>>>
>>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: user-unsubscribe@(protected)
>>For additional commands, e-mail: user-help@(protected)
>>
>>
>>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: user-unsubscribe@(protected)
>For additional commands, e-mail: user-help@(protected)
>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
|
|
|
