ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: Alias names for imported targets
Date Mon, 07 Jun 2004 12:16:14 GMT
> From: Nicola Ken Barozzi [] 
> Dominique Devienne wrote:
> >>From: Nicola Ken Barozzi []
> >>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?
> >>

No one was talking about java imports (which is just syntax sugar),
the anology is with java "extends" or most accurate with C++ extends
which can have multiple inheritance.

> >>Ant import is *different* from other mechanisms, so 
> analogies can help 
> >>but are not the same thing.
> > 

It should not be conceptually different. But given our adhoc
I am sure it is not going to match anything else out there.
The question is, shall we keep going further and further away form known
patters in CS or shall we try to bring ANT more in line with stablished
"good programming principles".

> > 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.

And when you extend a class you gain access not only the direct
methods but also all the methods that they call (which may or may
not be overriden by you or someone else exteding you).
The only control you have in inheritance is whether your direct to
a method uses the latest overriden implementation or the one before
you extended the class at all. There is no way to tell in your
call to use some other intermediate version. And if you are the class
defining the method for the first time, there is no way to tell it
to not use some non overriden version.

If you want to continue having access to some particular functionality
you need to give it a different name and make it either private or

In the case of ANT, if you want to have access to a particular
target across all levels you should give it a different name.
and write things like:

   <target name="thisTargetIwantToSeeAlways">.....</target>

   <target name="thisCAnBeOverriden"

One thing we lack is a way to declare a target "final" so it cannot be

> Namespaced Antlibs do not do this: what I get are extra 
> tasks, which do 
> not do things automatically.

I do not see any reason to include Antlibs on this conversation.

> > The closest cousin to Ant I can think of is XSL.

BTW, my original proposal for inheritance in ANT was to use the XSL
Nevermind I lost that one.

> 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.

So, what you are saying is that you are using the wrong tool for your
problem. I see no reason why we need to make import worst just so
that people can be happier to use it for the wrong thing.

Why should we provide more rope for people to hang themselves?

> 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.

Is there anything missing in macrodef that does not allow you using it?
Why, as you say, are you using the wrong strategy to solve your problem?

> 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.

To tell you the truth, I haven't found in my builds the killer app
for <import/>, but I have found numerous places to use <macrodef/>.

I think we need to start developing some patterns (AntWiki?)
on how to properly use the tools we have and detect what is missing
and what is pottentially bad coding, or tends to produce unmaintainable

I think we just now start to have enough experience to start looking at

Jose Alberto

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message