 | | | Target or macrodef? | Target or macrodef? 2004-08-25 - By Jeffrey Bacon
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)
|
|
|
