ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <>
Subject RE: Configure->Template->Build
Date Tue, 05 Jun 2001 16:13:18 GMT
At 04:35 PM 6/5/01 +0100, Jose Alberto Fernandez wrote:
>> >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? 

yep. Can only validate by running. Long time property of ant.

> or that you can validate the correctness of templates for all inputs?

almost impossible to prove correctness. People learnt this long ago.

>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.

read, think, learn. Go back and actual make an effort to understand why the
approach is wrong. Alternatively try to build a large scale project with
both methods. Without any practical experience or learning from people who
have had practical experience I can't see how you can expect anyone to take
your "opinion" seriously.

>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.

So what you are saying is that *if* you can validate the file (ie by
running presumably) and validate all it's inputs (again by runnning it)
then it will run. riiiight.

>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.

So can most programming elements. I once saw an example of Z specification
(validation/correcness proving language for PLs) that took something like
30 pages for a hal-page c program. Accept it that there is not a hope in
hell of ant "validating" anything like you suggest.

>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.

XSLT can offer similar features. You would know that if you knew XSLT.

>> 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.

er. You mean programming languages that have polymorphic representations?
Like that which was -1ed during voting. ok - good reasoning. PLs have
developed various mechanisms to get around this issue (interface in java
when passed to provider is a good example). Even PLs like C (who has the
lowest type safety of them all) don't allow such monstrocities to be



| "Faced with the choice between changing one's mind, |
| and proving that there is no need to do so - almost |
| everyone gets busy on the proof."                   |
|              - John Kenneth Galbraith               |

View raw message