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 14:21:59 GMT
Nicola Ken Barozzi wrote:

>> Yes, most build files have a target named "build" - but I don't know why
>> would you think about inheritance and OO instead of just qualified names.
>> I don't know _any_ programming language where import is used for
>> inheritance.
> Well, I pointed out xslt, what about that? ;-)

I know. Well, the behavior for properties in ant is inspired from XSLT as
But I don't think the import in XSLT is intended as an OO construct. Many
people don't think XSLT is a very good as a programming language ( even
if you can do a lot of logic in XSLT ). 

> As has been pointed out in these threads, Ant is a different beast, and
> should be treated differenty.


>> 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.
> Then call it <include>, it's already proposed.

Well, C uses #include, java uses import. I don't know if a lot of people 
will care if it's called one way or another. 

>> And if people need an OO feature for ant - that's fine, they can add
>> special tasks ( <exted>, <override>, etc ).
> Hey, that's what we are talking about! IOW, what should Ant give me to
> get the features I want?
> <include> ok, already decided
> <override> ok, already decided
> <import> ?

If include is already decided, then skip import. 

Add "extends" or something like that. 

>> We are talking about OO concepts and inheritance - in <import> context.
> Well, we are not. We are referencing those concepts, but it's not the
> same thing.

Still - replacing/overriding targets in import is very confusing, even on

My point is that we should eliminate ambiguities - but not by adding more
flexibility and complexity into the import task.

>> If we have so much trouble understanding how <import> would be used
>> for inheritance, what about all the users who may be java programmers
>> ( where import has a very intuitive meaning, and so does extends ).
> If it's just a naming issue, let's call it XYZ, I honestly don't care.
> Just to be clear: current import is *not* <projectref>. It is not meant
> to encapsulate another buildfile, and the basedir resolving and the
> non-namespacing of properties is very clear about this.

What is <projectref> ?

>> Well, we seem to be talking about which target will be visible - with
>> private/public and all this.
>> Very far from java import - where all you can talk about is qualified
>> names if you have 2 classes with the same name.
> Because Java does not have multiple inheritance, and even more does not
> have automatic multiple inheritance. I agree that this is a different
> concept.

If java doesn't have mutiple inheritance, why would ant need multiple
inheritance. Why would ant need inheritance at all is a different question

The real problem is that importing multiple files may result in the same
target name beeing defined multiple times. There is a very simple solution
to that - qnames. 

> Ok, so you haven't read all the thread ;-)
> Maybe it's better if you take a bit of time to reread the thread, as we
> are repeating stuff here.

I'm working on that :-) If I repeat some opinions - that's good.

>> If you import 2 files, each having a "compile" target, then you should
>> use qualified names. Like in java import.
> Ok, this is clear, you are saying we should not have an automatic
> "winner" in case of multiple colliding import names.

Yes. Having a "winner" is what creates confusion, ambiguity and the 
need to rewrite or define import as an OO construct.

>>>  target compile
>>>  target newcompile (call:prestuff, compile, poststuff)
>>>  target test depends=compile
>> That's a nice use-case - but why do you think this is a use case for
>> "import" ?
> Because I called it this way, that's all ;-)

What you want is:
  target compile
  target pre
  target post
  override name="compile" targets="pre,compile,post".

This can be done inside a single file, no need to use imports at all.

>> Just use a <rename-target> target, or some <pre>/<post> or <extend>.
> In fact, as I have explained, Conor proposed <override-target>, and I
> like it. But this is only about a a single import, the real issue
> discussed here is the multiple one.

I like it as well, but I don't agree that it is about a single import, it
can be very well used inside a single file, with no import at all.

If we agree on qnames ( and implicitely no "winner" or conflicts in import),
then override-target and all that becomes even more powerfull - you'll have 
access to _all_ targets, including the loosers.

>> So I consider a good thing that import doesn't allow you to "decorate",
>> but instead you should use a specialized task for this use case.
> You mean that a user must do:
>   <override-target name="xxx">
>   instead of
>   <target name="xxx"> (implicit override)?
> I'm fine with it, no problem here, again it has been proposed and
> accepted, but not the issue here.

No, that's not what I'm saying :-)

I'm not concerned with override-target - only with import and the resolution
of name conflicts. 

If people want to replace targets - great, but it's not my use case :-) A
clean import is what I need.

>>>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.
> Two points here:
>   - Crosstalk can happen in form of properties
>   - Of course you won't have crosstalk if you use qualified names, this
>     is what Conor says

Again, I agree with Conoer :-) That may mean he is right ?

I haven't tought about qualified names for properties, but it makes sense

> Let's see:
> <include>
> No problem here, any collision is an error

I don't quite see a need for include ( given my view on import :-), but
if other people need it - fine with me.

> <override-target>
> I am overriding the previous defined target, and can refer only to the
> immediately previous one as original.targetname. Overriding can be done
> multiple times, nesting the calls.
> <import>
> Like include, but gives me the possibility of referring to the imported
> tasks with a fully qualified name in any case. If there is only one
> version of a target, it's also available with the original name.
> <Still conused about this [] part> [The "namespace" name has to be
> specified as a prefix by the one that imports the file, else the project
> name is used. Projects that are imported must have a name.]
> If a project imports clashing target names, and thus namespacing is
> needed, I can still use <override-target> or <target> to define a target
> with the original name.


> Use case:
> multi-import(import a,b)
>    target test depends=a.test, b.test
> a
>    target compile
>    target test depends=compile
> b
>    target compile
>    target test depends=compile
> With namespacing I would get:
> a
>    target a.compile
>    target a.test depends=a.compile
> b
>    target b.compile
>    target b.test depends=b.compile
> Now If I redefine compile
> multi-import(import a,b)
>    target test depends=a.test, b.test
>    target compile depends=a.compile,b.compile
> Seems ok to me  :-)

> Now for Nick's usecase:
> "
> Nick Chalko wrote, On 01/08/2003 9.37:
>> I used this "feature" in centipede.
>> The release antlib has a target called tag-and-release, but it
>> depends on a target called tag However tagis expected to be defined
>> in a different antlib. Currently it is defined in cvsbuild, but it is
>> open for someone to make a vssbuild antlib.
>> So I do think cross talk is a "feature" but a feature that can be
>> hard to grok.
> "
>    multi-import(import release,cvsbuild)
>    release @importable="only"
>      target tag-and-release depends=tag
>    cvsbuild
>      target tag
> Seems that it should work with the above system.
> Also
>    multi-import(import release,cvsbuild,vssbuild)
> Would make it necessary for me to do:
>    override-target tag depends=cvsbuild.tag

I'm starting to like override-target :-)

> Anyway, it seems that all this discussion has brought us back to what I
> had proposed after Conor pointing out the issue:
> "
> Nicola Ken Barozzi wrote, On 30/07/2003 10.45:
> ...
>  > OTOMH this could be solved by rewriting all dependencies that are not
>  > in the import line.
>  >
>  >               (1)---a
>  >  multi-import (2)---b
>  >               (3)---c---d
>  >
>> So rewriting should block collisions between (1), (2), (3), but
>> enable them inside those lines.
>> What had been proposed is using "fully qualified" names in targets
>> that I do not want to be redefined, which could be ok conceptually,
>> but the issue is that the implications of sideways crosstalk between
>> import lines are not transparent to the user, and thus should be
>> avoided.
>> What I need is to be able to import build dependencies along with the
>>  targets. Probably the above solution should fix this error and make
>> it work, no?
> "
> Thanks for taking time to discuss this guys, I appreciate :-)

Sorry for repeating what has been discussed, I was very concerned about
mixing import with OO and complex name resolution rules ( like in XSLT
import :-)


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

View raw message