ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Bodewig <bode...@apache.org>
Subject Re: Names of import/include
Date Wed, 12 Nov 2008 05:22:41 GMT
On 2008-11-11, Dominique Devienne <ddevienne@gmail.com> wrote:

> On Tue, Nov 11, 2008 at 5:21 AM, Stefan Bodewig <bodewig@apache.org> 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):

I'm glad there is 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.

Technically the including build file could define a target with the
used prefix and still override any target.

We can certainly rewrite the docs to also say you can't override
targets unless you try hard to defeat include - in which case you
should use import.

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

This is not true for our include task, the different steps are
non-virtual as well.

> 2) You demonstrate the behavior by calling prefixed targets from the
> command line, which sends the wrong message.

No problem, I can easily add a dummy target that depends on the
prefixed target to the imporitn/including files and use that.

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

8-)

That's been my problem as well.

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message