ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Configure->Template->Build
Date Tue, 05 Jun 2001 15:35:58 GMT
> From: Peter Donald []
> At 01:44 PM 6/5/01 +0100, Jose Alberto Fernandez wrote:
> >Peter, parameterized software modules have existed in
> programming languages
> >since I guess Algol-66. And that is the analogy I used for
> <projectref>.
> >Templating, I associate more with Macro expansion. The basic
> difference
> >being that a template provides (in general) no syntax nor
> semantic checking.
> >Until you expand the template, in general, you cannot know
> whether the
> >result is a well formed thing or not.
> don't know where you would get that idea. 'Templates' in my
> experience is a
> way to create a instance based on particular parameters. What
> you describe
> makes me think you have used C++'s ugly templates ;)

There are at least 100s of systems that use the term "template" for what
they do. Most of them are glorified macro expansions. XSLT is no more than
glorified tree-based macro expansions. Or as they call it, itis a tree
"transformer" and as they say it can convert any tree into anything. I fail
to see how can you have any guarantees that a particular XSLT template will
produce the correct output for any given input. You will have to make
assumptions about the shape of the input. Assumptions that at least XSLT
cannot just verify for you unless you create DTDs etc, etc, etc.

> >As a parameterized module, <projectref> does not suffer from
> that. Since the
> >referenced project needs to be a valid <project> it can be verified
> >syntactically, semantically and in most cases it can be
> executed on its own.
> >You cannot do that with templates except for very few, and I
> would say
> >un-interesting, cases.
> false.

Can you give any argument? Are you saying that what I say about <projectref>
is not true? or that you can validate the correctness of templates for all

> The reason that I want static templating is for the
> extra safety it
> offers. If you really want to argue that dynamic templating
> is good then I
> think it would be best to go dig up the email sent last round of Ant2
> 'proposals' regarding this topic. So far no one has offered a clearer
> explanation of issues. Neither has anyone refuted his claim
> that dynamic
> templating is evil. Feel free to try.

You are the one calling our proposal "dynamic templating" I have never call
it that. So, since I do not think they are the same thing, and you do. I
think you will have to show us the isomorphism between the two.

Either dynamic or static, my comments about templates stand and since I am
making clear what I think are the diferences and advantages of <projectref>
against templating in general, I think I am making clear that the two are
not the same.

> >Look at this template, can the system verify that every
> expansion will
> >generate a syntactically correct ANT file? I do not think it
> can. Even with
> >input that may seem valid you can produce bad syntax (due to the
> >interactions of different xsl:templates, for example). You
> do not get that
> >kind of issues with <projectref> you can verify the validity
> of the referred
> >project on its own, and given valid parameters to the
> <projectref>, which
> >you can validate, you know the total is valid.
> err? don't be silly. projectref does not guarentee integrity
> anymore or
> less that other templating forms. Worse it defers many
> behaviour choices to
> runtime that could be done before hand.

As I said, a projectref by definition has to be a well formed <project> that
can be validated (using ANT). Once validated, you can reuse it without any
concern with respect to some bad input creating a badly formed project.

Instantiations of <projectref> can only pass values (either properties or
types) the project doing the instantiation will only be valid if properties
are well defined and all typedef values follow the syntax of the type. This
can also be validated.

If I add more levels of <projectref> these rules apply the same way. If you
modified one of the included projects, as long as you do not change types
used in instantiations or rename target used ourside, you only need to check
the validity of the modified project to guarantee that any calling project
will continue to be valid.

I doubt you can make the same claim for any valid XSLT, Velocity, or
whatever other template paradigm you may want to use. If by template
expansion (instantiation) you mean something else, well you need to define
it properly. I am using the clasic definitions of the term, here.

> >This is a much more modular approach.
> you have got to be kidding me. Maybe for toy projects but
> they are not who
> this is provided for. Spagettis is what this produces - as thread of
> execution travels between each project constantly changing frames,
> terrorizing anyone who has to read it and try to understand
> the values of
> things without executing it.

You mean just like what happens during method invocations in modern
programming languages? Did not know people got terrorized about that.

Jose Alberto

View raw message