> From: Costin Manolache [mailto:[EMAIL PROTECTED] > > Nicola Ken Barozzi 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. > 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. > 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. > > 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 ). > In Java, import has nothing to do with file inclusion, it just provides syntax sugar. You could "import a.b.C;" and then every usage of "C" referes to "a.b.C" or you may omit the import statement and use "a.b.C" all the time. So it is clear we are not talking Java-imports here. > > > 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. > We have never been talking about java imports. I do not know why you are assumming we were. > > > > 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. > Still, what do you do when including the same target name more than once? > > > 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. > > 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. > > 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 - Agreed. But you should be able to redefine the target (override) and say what do you want it to mean. > > 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. > > > > 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. > > > 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 :-) > Who sed we were trying to implement <copy>? :-) Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
