> From: Conor MacNeill [mailto:[EMAIL PROTECTED]
>
>
> > 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 version;
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:
visibility="final|private|overridable"
you may decide what should be the default.
3) targets can be overriden using <target/> which replaces the target
completely. Or using
<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 is
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">
....
</target>
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
a->precompile.
Ok, I will stop now, we can talk about implementation later.
Jose Alberto
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
