Re: enhancement, it's done, but do you like how it works ?

[Nicola Ken Barozzi]

Jose Alberto Fernandez wrote:
From: "Nicola Ken Barozzi" <[EMAIL PROTECTED]>
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.
Ah, ok, it's an extra level of expansion,  understand.
Then it's better IMHO to not use the same syntax because it can confuse 
users.

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.
And I'm doing rewriting because of the flat space ;-)
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.
Yup, that's what I meant.
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.
Yes. But this makes the order og declaration important.
It's how XSLT treats imports I think, but I find it a bit confusing...
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".
Yes, this is better.
I'm more geared towards checking the semantics more than the 
implementation syntax ATM.

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.
You are correct, it doesn't, but targets yes (same name, different files).
Let's divide the problem in two:
1. targeta is both in builda and buildb, and both are imported in buildc 
that rewrites it.

ie
  builda
     targeta
  buildb
     targeta
     targetb depends targeta
  buildc
    import buildb
    import buildc
     targeta extends super.targeta
I call targeta in buildc.
What should happen here?
It seems that only targeta in builda will be imported, thus:
  builda[targeta]->super.targeta
  buildb[targeta]->targeta
  buildc[targeta]->targeta
                  ^^^^^^^^^^^^^^^^^
                    for all
Correct?
Basically the first gets rewritten but buildb uses that too, ie the 
buildb implementation is effectively discarded.

2. targeta in builda gets rewritten in buildb, and that in buildc.
  builda
     targeta
  buildb
    import builda
     targeta extends super.targeta
  buildc
    import buildb
     targeta extends super.targeta
I call targeta in buildc.
What should happen here?
It seems that we need:
  builda[targeta]->super.super.targeta
  buildb[targeta]->super.targeta
  buildc[targeta]->targeta
                  ^^^^^^^^^^^^^^^^^
                    for all
Correct?
(Apart from super or super() or whatever, let's focus on the logic for now)
--
Nicola Ken Barozzi                   [EMAIL PROTECTED]
            - verba volant, scripta manent -
   (discussions get forgotten, just code remains)
---------------------------------------------------------------------
--
To unsubscribe, e-mail:   <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>