ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject Re: <import> enhancement, it's done, but do you like how it works ?
Date Fri, 12 Jul 2002 00:31:07 GMT
From: "Nicola Ken Barozzi" <>

> Jose Alberto Fernandez wrote:
> > I am suggesting a rewriting scheme that renames each
> > overridden target with the file it comes from:
> > 
> >   targetA --> path/A.xml::targetA
> > 
> > and then having ${ant::super(targetA)} expand to the
> > correct rewrite:
> > 
> >   <target name="targetA" 
> >           depends="${ant::super(targetA)}"/>
> > 
> > becomes:
> > 
> >   <target name="targetA" 
> >           depends="path/A.xml::targetA"/>
> > 
> > this is robust no matter how many levels of nesting
> > you have.
> Ok, now I understand :-)
> We could have roughly the same by doing something /like/:
>      <target name="targetA"
>              depends="imported.A.xml.targetA"/>

If I, as a user, have to use the the rewritten syntax, then we are not talking 
about super anymore. It also means that if I rename an imported file I need to go
all over my code changing the names of all the targets inherited.
That to me is very very bad.

> I don't like your syntax that much, and the property use too,
> since users may want to set the value with a property, but
> they cannot easily, because you would need double property expansion...

My main point is that you need to use some symbolic representation
for super. A simple string is not good enough. I propose using the syntax of
properties because it is already part of the language. You can propose something
diferent, but it has to be something we can treat as a reserved word.
I could not imagine anything else available, hence the use of ${...}.
You could just use: ${super(targetA)}.

Notice that this special syntax is expanded by ProjectHelper way before
regular property expansion, hence all this issues about double properties
really do not exist.

> Basically what you are saying is that using many super.super. etc can 
> lead to subtle errors with multiple imports...
> hmmm...
> It's because we have a flat space, and so we don't have proper nesting 
> and encapsulation...

It is not the flat space, but the fact that you are doing rewriting for your compilation.

> Let's say that builda.xml imports buildb.xml, which imports buildc.xml.
> Also builda.xml imports directly also buildc.xml.
> All have targetc.
> Now, will targetc of builda.xml override the one of buildb.xml or of 
> buildc.xml?

The override itself is not an issue, but any call to super(targetc) may be.
However, we probably need to take a look at how the "include" part of
<import> works. If I remember correctly it will only add buildc.xml once
and ignore any other loads.

> It's like name clashing in Java, where different packages are made to 
> prevent it.
> Basically imported builds are imported packages, so they must have 
> unique names somehow.

That would not solve the problem, since you are adding the same file "buildc.xml".
The issue here is that multiple imports define multiple inheritance, and these are the
kind of problems you get in languages that support multiple inheritance.

> Since we have a flat system, the most simple way is that every imported 
> targets can also be called with the full path (sort of...)
> Still not sure that this fixes the problem though...

That is way too ugly. If we have to get to that I would prefer some symbolic reference.

<import file="buildb.xml" id="b"/>
<import file="buildc.xml" id="c"/>

<target name="x" depends="${super(c::targetc)}"/>

or something to that effect. Notice that in the example "targetc" is not necessarily
in "buildc.xml" but t may be in some other file imported by "buildc.xml".

> Dr. Pietschmann ;-) any hint on how XSLT works with these problems?
> I'll be looking now in the specs, but I'm sure that your Mulberrylist 
> experience can be again of some help :-)

I think the rules for this cases are quite complicated and involve priorities and
all other kinds of definitions. Anyway I do not think the current <import>implementation
allows loading a file more than once.

Jose Alberto

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

View raw message