Nicola Ken Barozzi wrote:
>> Thanks for the overview, Nicola ! >> >>>Just to get you up to speed, the current issue is about multiple >>>inheritance, and how the current system allows cross-import (unwanted?) >>>side-effects, as Conor has brilliantly shown. >> >> What I'm not sure I understand is what import has to do with multiple >> inheritance :-) > > Because we can import two targets with the same name from different > files. Making them work together is conceptually similar. You could try to import 2 classes with the same name in java. It's a syntax error - and if it happen, you must use qualified names. 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. >> What's the syntax for the >> prefixed targets/properties ? > > prefix+targetname > > example: > prefix="a" > name="b" > result="ab" Hmm. Some delimiter would be good to have. a.b, a-b, a::b, etc. It would make things easier to read and understand. It would also be nice to default to the project name ( and require it to be unique, or use the explicit prefix only if 2 build files have the same name ). >>>- add <include/> task, like entity includes >>>- add <override-target/> task to override targets >> >> Is this "override-target" a substitute for <extends> and OO use of >> ant ( i.e. a buildfile == class, target==method ) ? > > In a sense yes, but not quite. Import does not fully encapsulate the > calling buildfile. @see XSLT include and import for a more similar > concept. > >> If so, wouldn't be more intuitive to just use the real concept - i.e. >> extends and inheritance ? > > Dunno. > >> I know python has a very nice namespacing mechanism where you can replace >> or add methods dynamically to an object, but I don't know if this is >> desirable for ant. > > KISS. Personally I don't need that (yet) I guess. 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. And if people need an OO feature for ant - that's fine, they can add special tasks ( <exted>, <override>, etc ). >>>Threads about import (in order): >>> 1 - ImportTask ant 1.6 >>> 2 - ant 1.5.4 : Import >>> 3 - override >>> >>> From thread 2 I wrote: >>>" >>>multi-import(import a,b) >>> target test depends=a.test, b.test >>> >>>a >>> target critical >>> target test depends=critical >>> >>>b >>> target critical >>> target test depends=critical >>> >>> >>>Here "critical" means a.critical to a and b.critical to b, but since >>>they reference a generic "critical", they get the only one that remains >>>after being redefined. The problem is that I did not redefine it in the >>>main buildfile! >>>" >> >> Can this be resolved by making all targets qualified after the build file >> is read ? > > This is what Conor seems to propose IIUC, and what others are not keen > on, and instead talk more about the xslt-type import. Well, Conor has one more vote then :-) XSLT is not the easiest XML format ( I don't know many people to consider writting an XSTL is easier than writting an ant build file :-) And the fundamental problem ( IMO ) is using the wrong concept. We are talking about OO concepts and inheritance - in <import> context. 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 ). > Just remember that we are not talking about renaming properties, or > resolving basedirs, so it's not full encapsulation, but just > dependency-shielding. 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. > I have not yet made up my mind, but it seems that ATM there is a reason > favor some kind of "namespacing" because I see more harm than good in > side-effects that come out of not doing it. How this can still solve my > usecase is yet to be seen. Maybe import shouldn't solve all use cases - just have a different task that solves overriding/replacing some targets. >> When you look at a build.xml, all targets that don't have prefix are >> resolved to the current build file - it's pretty easy to understand. >> >> That mean you won't be able to use import for crazy overrding of >> some targets from one file with targets from other file - but if there is >> a real need for that i have no problem with a python-like mechanism where >> you can add/replace methods in an object at runtime. As long as it's >> not disguised as <import> :-) > > Well, IMHO I personally don't see a real, strong, compelling reason to > have targets have crosstalk between themselves, but I do have an equally > strong need to import dependencies. With qualified names, you can have both. > As I have outlined before, imagine I import a file that has a compile > and test targets. > > target compile > target test depends=compile > > I want to be able to do "ant compile" and have it compile. Thus the > compile target should not be renamed. If this is the only "compile" target in all the imported files, then you should be able to say "ant compile". If you import 2 files, each having a "compile" target, then you should use qualified names. Like in java import. > Then when I want to insert a pre-condition to the compile target, I want > to be able to redefine the compile target. > Reusing it in a differently-renamed target is not ok, as when I call > "test", it will not have a dependency to the new version of the target. > > 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" ? Just use a <rename-target> target, or some <pre>/<post> or <extend>. > If I call newcompile, it works but calling test will not call the new > one, thus making it impossible for me to *decorate* the compile target, > thus specializing the template. Makes sense to me - if import would allow this to happen few people will be able to understand a build file. 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. > The question is: after a multiple import, which compile target becomes > the "default" one, ie the one without renaming? None, if 2 targets with the same name are found, you must use qualified names for both ( when calling from outside - all dependencies and calls from inside an imported build.xml file would use the short name ). > 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. > 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 ? > As you see, for this usecase, <include> is not strong enough, as I > cannot override, and complete namespacing prevents me from overriding > the dependency chain. It's like saying <copy> is not strong enough to compile java code :-) Costin --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
