> From: Conor MacNeill [mailto:[EMAIL PROTECTED] > > > > > What stops you from writing two separate buildfiles one for each > > that perform the import and do the respective override. From your > > main build you just <ant/> these new files. > > Probably nothing, especially in this particular example. > However, not only > should I not have to do that, there will be situations where > I want to bring > two fragments together and have them interract in a controlled way. > Providing <import> and then telling people they need to use > separate build > files to avoid unforseen interactions is not right. > > > > > My point in all these is that <import>ing all files toghether > > may not be the only way (or the correct way) to solve every problem. > > And the more I see at these examples the more I think that we are > > going the spaggetti way; I think I preffered a well layered > lassagna :-) > > The funny thing is that to me it looks you are eating > spaghetti :-) We need > to support use of unrelated fragments or the concept of > import will not > scale. > > > > > Well that is the way it works in OO programming. If you redefine > > a signature, implicitly, you get the new behavior. > > What you are describing is not the way OO works, IMHO. > Imagine in Java, if > when you import some code it affected the operation of some > other unrelated > code you also imported. In OO, you decide what it is you > override, it does > not happen because you just import two classes that both > define an init() > method. > > The problem is the scoping/namespacing. It is <import>'s > current weakness. >
The weakness in your argument is that Java was carefully defined so that you cannot extent two classes in order to avoid this issues. Secondly, Java provides global names for the objects i.e., fully qualified names. The closer you can get in Java to this issues is to think in terms of interfaces. An interface may inherit multiple ones. Those inherited interfaces may define the same method as part of such interfaces. Even if the interfaces are completely unrelated and the intended behavior suppose to be very different, any actual implementation will only have one implementation of the method which will be made available from all extended interfaces. So you see, there is no way in Java to say I want the version of the method for interface A, or I want the version for interface B. The method is the method. > > > > BTW, I am not against having some different approach as > long as it is > > well defined and not something that works for the two or three > > scenarios that come to mind and breaks all over when users > > try to do something interesting. > > I think your usecase is catered for if you leave out the prefixes. > > > > > I would argue rewriting is not the solution. If we want what you > > are saying, then we need a more richer execution context framework > > where dependencies are selected depending on the target that > > is citing them (and not just by name). All that is possible by just > > managing better the symbol tables for targets. > > You may be right. You know I have played with this sort of > hierarchy of > projects before. OTOH, I would say that rewriting is one way > to achieve > separation and it is in fact a common solution to partitioning a flat > namespace - c.f. C++ name mangling. > > I will do some more experiments to see if I can come up with a clean > solution which also addresses Dominique's target visibility ideas. > Just to mention, name mangling in C++, IIRC, is not for the code writer consumption. It is for the mapping of the code to the symbol tables of the C compilers and linkers below. All the resolution of the semantics of the language is done before name mangling takes place. Also notice that in C++ you have "virtual" and "non-virtual" methods which have completely different resolution rules (Java only has virtual). It seems to me part of the issue is that we do not distinguish between this different behaviors but we still want them to have both. Jose Alberto --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
