ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <>
Subject RE: override
Date Tue, 05 Aug 2003 18:59:08 GMT

> From: Conor MacNeill []
> > All the resolution of the semantics of the language is done
> > before name mangling
> This is not strictly true. In C++ you decide (by using extern 
> "C") whether
> to place a symbol in the global namespace or its own (by name 
> mangling). The
> programmer needs to be aware of this. C++ also introduced the 
> namespace
> concept due to the likelihood of Class name collisions, since 
> prior to that
> Class names occupied a single global namespace.

Just for closure on this comment, all the stuff with extern "C"
in C++ is not for the user programming in C++ but to allow
interoperability between C++ and C. Which is a completely different
suubject. I am the first to think that C++ became one of the worst
amalgamations on features on the planet.

And I definetly do not want ANT to go that way, that is my fear.

> > takes place. Also notice that in C++ you have "virtual" and 
> "non-virtual"
> > methods which have completely different resolution rules (Java
> > only has virtual).
> > It seems to me part of the issue is that we do not distinguish
> > between this
> > different behaviors but we still want them to have both.
> >
> So, what is your proposal? How does it address my usecase? I believe a
> non-prefixed import addresses your usecase.

First I do not think I have all the answers, just to keep things in perspective.
What I think I have is a set of principles that I think any viable solution
should provide. Lets see if I can put them into words: ;-|

1) I should be able to determine the correctness (loosely used here) of a buildfile
by looking at that buildfile (and its dependencies) in isolation. This means that
the fact that I am imported by someone else should not affect my correctness
(modulo overriden targets).

	Rewriting of targets, may attempt at this correctness.

How can we get something more interesting out of that principle above, I agree is
quite generic. Lets see...

2) It would seem we need to be able to specify whether a target can be overriden
or not. We need to be able to define if a target is: private, final, or overidable.
Notice that this is a property of the target and not of the way the target is imported.

The meanings are:
 private ==> other targets with same name on other files will not override; 
             any mention on dependencies on this file for that target will use this private
		 the target is not visible from outside the file.

 final ==> target visible from other files but not overidable, it is an error;
           any mention on dependencies on any file (without a private def) uses this version.

 overridable ==> target visible from other files, and overridable;
                 any mention on dependencies on any file will use top level available version.

this are just suggestions, other levels of protection may be possible.

On a project-fragment, any target dependency not defined in the fragment will be picked up
from the
visible targets, following the rules above.

I would suggest an attribute like: 


you may decide what should be the default.

3) targets can be overriden using <target/> which replaces the target completely. Or
<override-target> which allows expressing dependencies on the overriden target.
The syntax in the dependency list is to mention the name of the target itself n the list.

   <override-target name="compile" depends="precompile, compile, postcompile"/>

The "compile" target in the dependency list refers to the overriden target.
Notice that <override-target> requires target name to already exist and be overridable.

4) To support multiple inheritance, I would allow defining a name for an import. This name
only visible locally and can be used to specify in a dependency list a target comming
from an specific import. You can refer that way to any target visible from that <import>
but you cannot refer to inner <imports> of those that have been overriden.
You cannot use the notation to break the visibility rules.

  <import file="xyz" name="a"/>
  <import file="qrs" name="b"/>

  <target name="compile" depends="a->precompile, b->precompile">

If xyz uses some other import that it names q, I canot say a->q->precompile, because
that violates the visibility rules defined in xyz that provided its own target

Ok, I will stop now, we can talk about implementation later.

Jose Alberto

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

View raw message