On Tue, Nov 11, 2008 at 5:21 AM, Stefan Bodewig <[EMAIL PROTECTED]> wrote: > after I've added include I'm not too sure about its name. What we > call "import" is called "extends" by EasyAnt and our "include" is > EasyAnt's "use".
First, it's a good description of the consequences of the current and enhanced code Stefan. Thanks. But (there had to be one): 1) <include> to me means that the target itself can't be overriden, while you describe that it's its dependency list that cannot be changed. To again make a Java analogy, an included target is like a non-virtual template method pattern delegating the different steps to virtual methods, aka the targets listed as dependencies. The target is thus final in its definition, cannot be overridden, but what it depends on is not "hard-wired" to given targets. This again mirrors XSLT, where included templates cannot be overriden by names, but when they call apply-templates or call-template, "virtual dispatch" is in effect. 2) You demonstrate the behavior by calling prefixed targets from the command line, which sends the wrong message. Prefixes should never leak to the build users IMHO. They should be implementation detail of the build. I guess I'm just lamenting that the current import and the new include don't behave the way I'd expect feature with such names to work, from my XSLT biais, and the analogies I draw to Java/OOP for them. It's too late for import, and its legacy implementation is now "polluting" the include semantic as well. As usual I'm not being pragmatic :) Cheers, --DD PS: back to your description, if we'd put more emphasis on the different uses of the two, rather than the low level consequences, it would be more user oriented. Trouble is, given the behavior described, I wouldn't know how to spell out these uses... --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
