ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Costin Manolache <cmanola...@yahoo.com>
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
well. 
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.

+1


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

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.



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


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

+1


> IMPORTANT PART
> 
> 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  :-)

+1
 
> 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 :-)

Costin


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


Mime
View raw message