ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jacob Kjome <h...@visi.com>
Subject RE: Target or macrodef?
Date Wed, 25 Aug 2004 16:14:38 GMT
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@attglobal.net>:

> 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@wilandra.com or billrich@attglobal.net
> http://www.wilandra.com
> 
> -----Original Message-----
> From: Jacob Kjome [mailto:hoju@visi.com]
> 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@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

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


Mime
View raw message