Dominique Devienne wrote:
...From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED] Jose Alberto Fernandez wrote:
All this restriction in OO inheritance are there to limit developers capability of writing spaguetti. We still do, but...
Import overriding is not about OO inheritance, it's about target dependency injection, which is not quite the same thing.
Look, if you import in Java packages that have the same class and then want to use a specific one, you must use fully qualified names. Why can't I in Ant? What does this have to do with inheritance?
Ant import is *different* from other mechanisms, so analogies can help but are not the same thing.
Hmmm... I've recently read quite a bit about dependency injection and IoC on the Spring, HiveMind, and MartinFowler sites, and I don't think Ant's import/target override mechanism has anything to do with it. I think you must be meaning something else that what this term has recently been used to describe...
:-)) Yes, I mean something different, and it's funny to see this misunderstanding.
What I was trying to say is that importing targets one gets new target dependencies, not only new targets.
Namespaced Antlibs do not do this: what I get are extra tasks, which do not do things automatically.
When importing instead I get targets that can automatically get wired to others, thus getting called in the existing dependency resolution.
The closest cousin to Ant I can think of is XSL.
Again, another analogy! :-)
XSL has a proper
include/import model, and also the Java equivalent to super., where
an overriding matching template can explicitly invoke the overridden
template. But that's it! You can never otherwise distinguish what
comes from the main stylesheet from what comes from included or imported
stylesheets, directly or not.
It's still different...
Having this access just break encapsulation and would lead to spaguetti buildfiles, as Jose Alberto puts it.
I see that you two are particularly firm in this, and to be honest I'm just trying to play the other side for the sake of discussion. On the pther hand, I am not convinced by your reasoning, as it's subjective, not objective (mine is too).
Let me try to take a step back and ask you a question: what is <import> for?
Originally it was to do all sort of things for extending builds, but then some very clever coder came up with macrodef and typedef, and most of the reasons of import fell.
If I want a particular target to be called, I should not want a target, but a macrodef. When <import> was first put in there, some really wanted it to work like a sort of macrodef, and most, including myself, are using it for this purpose.
In *this* case, having the feature discussed here makes sense. In *this* case, using the inheritance analogy does *not* make sense. IMHO this is the reason why we are not understanding wach other, as we think of different use cases.
Could it be that we should simply hint that in this case one should use a macrodef instead of a target? I start to think that this 'feature' should not be allowed because of this.
--
Nicola Ken Barozzi [EMAIL PROTECTED]
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
