ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <>
Subject RE: override
Date Fri, 08 Aug 2003 13:58:11 GMT
Jose Alberto Fernandez wrote:

>> I don't know _any_ programming language where import is used for
>> inheritance.

> Believe it or not, XSLT is a programming language. :-)
> And it uses the term import for inheritance.

I know XSLT is a programming language, I don't remember it beeing an "OO" 
language. And I certainly don't think ant should become a programming
language like XSLT. 

>> Well, KISS is my concern as well, for <import> ( which at
>> least in my mind
>> is _very_ different from "extend" ). I preffer to use import
>> to just import
>> entire files, instead of some attributes and sophisticated rules to
>> determine what target is visible and what target is overriden.
> What does it mean "importing" an entire file? I have heard on other
> languages of "including" an entire file: C, C++, etc.

Yes, C uses the keyword "#include", Java uses "import".

I think import is more intuitive for java programmers, and I'm not sure 
I get the subtle difference between <import> and <include> or why we 
need both ( unless we want to get some complexity from XSLT ).

>> And if people need an OO feature for ant - that's fine, they
>> can add special
>> tasks ( <exted>, <override>, etc ).
> It is not that easy, you most probably need to change the
> execution engine, to do it right. Which means changing some of the
> internal DS of Ant. So it is not just a little task, here and there.

That's another argument to keep import simple ( and not turn it into
 an OO concept ). 

> We have never been talking about java imports. I do not know why
> you are assumming we were.

Because <import> is making the targets of one file visible in another one.
You can consider python and other languages  (except C/C++ ) where similar
constructs are used.

>> Maybe import shouldn't solve all use cases - just have a
>> different task
>> that solves overriding/replacing some targets.
> Still, what do you do when including the same target name more than once?

Use qualified names. 

   all  depends compile
   all depends compile
   import a,b
   all depends a::all, b::all, compile

Import a will load a and qualify the names. The equivalent view is:

   a::all depends a::compile
  b::all depends b::compile

  import a,b
  c::all depends a::all, b::all, c::compile

There is no conflict between the 3 compile targets, and each can be 
used in an unambiguous and clean way. More important - you have access to
all targets in all files, and no need to worry about what is overriden by
what or order of imports or deep imports. Doesn't matter how a file is
imported, you can use all its targets.

>> If you import 2 files, each having a "compile" target, then you should
>> use qualified names. Like in java import.
> In Java the qualified name is intrinsic to the imported file;
> but in the current proporsals the name is given by the importing build,
> this makes names not to be unique.

I consider that an error.

If the name is not unique - then report an error.

We already have a name in the <project name="XXX"/>, and I'm not sure why
we want to define another name given to a project in import, and to add to
the confusion - allow a project to be reffered by different names, and
worse, to have the same name used for different projects in import

Just add the requirement that in order to use import, the project name must
be unique, and report an error if 2 files with the same project name are

>> None, if 2 targets with the same name are found, you must
>> use qualified names for both ( when calling from outside -
> Agreed. But you should be able to redefine the target (override)
> and say what do you want it to mean.

Ok - you should be able to say:
 <alias name="mycompile" target="a::compile" />
or even
 <replace name="a::compile" with="b::prepare, a::compile" />
( what Nicola seem to want ).

But not as part of import - this is a different story, different task.
It is easy to manipulate the namespace of the project - after the loading
is done - and do any kind of changes ( again, python comes to my mind )

>> > Second question: how do we deal with the fact that targets
>> that are not
>> > even used have crosstalk between themselves?
>> I don't think you can have crosstalk if you follow the rule
>> that everything
>> is qualified if it has the same name.
> The probelm with tis is that it does not allow you to write code
> fragments. Like several blocks of initializations that can be
> reused but do not define a full build process.

Why not ? It just requires you to use them with a qualified name or make
their names unique.

What it prevents is confusion if you have 2 fragments using the same name.

>> > And most of all: how to solve the last two points while keeping it
>> > possible for me to retain the use-cases?
>> By adding specialized tasks for your use case ?
> That is what we were trying to do.

I'm confused, I tought we are discussing import :-)


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message