Guys,
I think that using C++ or C# as the model for ANT inheritance would be very bad.
As I remember, the rules for resolving multiple inheritance in C++ are
very complicated.
I would propose using the XSLT model. It is much more simple, it may not
allow for the example posted below as is, but I think it provides a well
defined model and a simple set of rules.
In escense, the idea is to associate a precedence to each target (template in
XSLT)
and when we say target X in a dependency, what is meant is the highest
precedence X.
No renaming necessary. Additionally, XSLT has an <apply-imports/> which would
be
equivalent to having a task like: <call-import/>
which evaluates a target with the same name as the current target but comming
from the
imported files (not taking into account the current target, nor targets on files
importing this build file).
How to associate precedences, very easy. If we have something like:
a+---b---c
\---d-+--e
\--g \-f
target precedence on each file will be:
c=1 b=2 e=3 f=4 d=5 g=6 a=7
So if X is defined in c, e, and f; everybody will finish using the one in f.
If X calls <call-import/> then it will call the X in e, since it is the highest
definition
lower than the X in f.
Shall <call-import/> execution make sure its dependencies have been executed?
Or shall
it be executed without dependencies (That I do not know).
Notice that there is no need for renaming anything, just adding a precedence
attribute
to each target. And precedences are assigned in a depth-first-search manner.
XSLT forces <imports> to be at the top of the file, which simplifies precedence
computation.
We could enforce the same (what it really means, is no imports inside targets).
Well, hope you consider this, as an alternative. I think it is much more easy
to handle
and if XSLTs do not need more that this, I do not see why ANT will need much
more.
Cheers,
Jose Alberto
> -----Original Message-----
> From: Nicola Ken Barozzi [mailto:[EMAIL PROTECTED]
> Sent: 30 July 2003 09:46
> To: [EMAIL PROTECTED]
> Subject: Re: ant 1.5.4 : Import
>
>
>
> Conor MacNeill wrote, On 30/07/2003 0.10:
>
> > On Tue, 29 Jul 2003 05:52 pm, Nicola Ken Barozzi wrote:
> >
> >>Personally, I don't see the real need for it, as the same
> can be done
> >>with correctly-written @importable files. In the specific,
> init values
> >>should be included rather than imported.
> >>
> >>Can you point me to some relevant use-cases?
> >
> > Ok, attached is a small test case which shows the failings
> of <import> when
> > there are target name collisions. In this case the
> dependency of "test" to
> > "critical" in b.xml is incorrectly replaced with a depenency on the
> > "critical" target in a.xml.
>
> Woah, this is a really nice test!
>
> I strongly encourage all that are interested in <import> to
> unzip it and
> run it, it's very insightful.
>
> > Target renaming doesn't help here. Having everything in a
> single project
> > namespace remains a problem. I'd say the number of target
> name collisions
> > between imported build files is going to be high because of
> the tendency to
> > choose target names from a small pool of common names.
>
> Houston, I think we have a potential problem here. You are right.
>
> I have never encountered this because I always write small imported
> files with not many targets, and each library has unique-name targets.
>
> The issue stems from the fact that overriding works also *between*
> imported files. So what happens is that an imported file silently is
> able to override a target in another imported file without me knowing
> it, and I agree that it's nasty.
>
> Let's see what the behaviour should be here.
>
> multi-import(import a,b)
> target test depends=a.test, b.test
>
> a
> target critical
> target test depends=critical
>
> b
> target critical
> target test depends=critical
>
>
> Here "critical" means a.critical to a and b.critical to b, but since
> they reference a generic "critical", they get the only one
> that remains
> after being redefined. The problem is that I did not redefine
> it in the
> main buildfile!
>
> OTOMH this could be solved by rewriting all dependencies that
> are not in
> the import line.
>
> (1)---a
> multi-import (2)---b
> (3)---c---d
>
> So rewriting should block collisions between (1), (2), (3),
> but enable
> them inside those lines.
>
> What had been proposed is using "fully qualified" names in
> targets that
> I do not want to be redefined, which could be ok
> conceptually, but the
> issue is that the implications of sideways crosstalk between import
> lines are not transparent to the user, and thus should be avoided.
>
> What I need is to be able to import build dependencies along with the
> targets. Probably the above solution should fix this error
> and make it
> work, no?
>
> Other suggestions on how to do it while keeping the
> functionality that
> import now gives?
>
> --
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
