Target or macrodef? 2004-09-01 - By sebastian ssmoller
hi,
sorry for the late response ...
i would really love to see that feature in ant. maybe in 1.6.3 ?
i still think that it makes <macrodef/> more reusable and (at least in
this case) the code is more readable and maintainable than the
work-around of generating properties cause it makes the intention of the
coder clear. (just my 2cents ;-)
so how to go on from here ? anybody any plans commiting the "<local/>"
patch/change?
thx
regards,
seb
On Wed, 25 Aug 2004 16:41:22 -0400
"Inger, Matthew" <Inger@(protected)> wrote:
> As a followup to my comment about local variables in macrodefs, turns
> out,
> it would only take a few lines of code over 3 classes to make it
> happen:
> 1. PropertyHelper - add ability to remove a property
> 2. MacroDef - allow a <local> subelement
> 3. MacroInstance - cleanup local variables after execution
>
>
> <macrodef ...>
> <local name="abc" />
> <sequential>
> <property name="abc" value="xyz" />
> </sequential>
> </macrodef>
>
> With the <local> element in there, it's telling the macrodef that
> the property "abc" is local, and should be removed when execution is
> finished. I had tried to be able to replace <property> with <local>,
> so
> that you didn't have to seperate the declaration of it being local and
> the
> definition of it's value. However, it looks too complicated for
> someone
> who's not that knowledgable about the inner workings of the ANT code
> to do
> very easily.
>
> -----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)
>
--
"Perfection is achieved, not when there is nothing left to add,
but when there is nothing left to take away."
--- Antoine de St. Exupery, Wind, Sand, and Stars, 1939
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@(protected)
For additional commands, e-mail: user-help@(protected)
|
|
