ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Diane Holt <hol...@yahoo.com>
Subject Re: Configure->Template->Build
Date Thu, 07 Jun 2001 18:53:51 GMT
--- Peter Donald <donaldp@apache.org> wrote:
> Iteration and selection should really only be used in
> rule/template/generic targets and thus only used by experienced people.
> Including these features in the core would however mean novices would
> use them ... probably in bad ways ;) Worse we would have to support and
> explain to them, "no don't use if ask there, use multiple targes with if
> attribute, don't use repetition here, explicitly list the data etc".

I have to disagree with this. I don't think what functionality Ant offers
should be determined by whether it might be used "in bad ways".  I've
cleaned up plenty of cruddy code -- C, shell-scripts (all the variants),
make (all the variants), jam, you name it -- and never once did it make me
think, "Yuck! -- 'X' must really be a crappy tool, it's being used so
badly."  I just think, "Man, whoever wrote this sure didn't know what the
hell they were doing."

> Already there is some people claiming the documentation is lacking, but
> we add these features in and we would have to add in documentation about
> build practices to avoid, ones to run towards etc. 

Nor do I expect to find documentation for the tool that would say "Don't
do it this way -- do it this way instead" -- I expect to learn that by
trial-and-error and (maybe) some good (as in: done well) examples.

> By separating repetition and selection into another layer (ie
> templating), it saves us mountains of hassle and ensures that people
> using it will have a clue (or at least to some degree).

I just don't see that -- if it's being offered, whether inside or out,
it's still connected, officially, to Ant, and you're right back where you
say you don't want to have to be (supporting and documenting it).  As I
think I've mentioned before, the change to allow the if/unless to test for
equality (for any value [including being specified as a property], not
just for true or false, as was recently mentioned) adds only about 5 lines
of code, and, if anything, reduces the level of complexity needed to
explain how to use it, since it doesn't requires jumping through a bunch
of separate targets to finally get back to where you started, but instead,
is all just right there: <target name="state" unless="sane=${sanity}">.
Having a <condition> task would also seem like a straightforward way to go
-- as would (does, now that's it's [unofficially] available) a <foreach>
task.

Diane

=====
(holtdl@yahoo.com)



__________________________________________________
Do You Yahoo!?
Get personalized email addresses from Yahoo! Mail - only $35 
a year!  http://personal.mail.yahoo.com/

Mime
View raw message