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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
