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