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 constructed. Cheers, Pete *-----------------------------------------------------* | "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 | *-----------------------------------------------------*
