ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicola Ken Barozzi <nicola...@apache.org>
Subject Re: <import> enhancement, it's done, but do you like how it works ?
Date Fri, 12 Jul 2002 08:25:44 GMT

Jose Alberto Fernandez wrote:
> From: "Nicola Ken Barozzi" <nicolaken@apache.org>
> 
>>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                   nicolaken@apache.org
             - verba volant, scripta manent -
    (discussions get forgotten, just code remains)
---------------------------------------------------------------------


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message