PROPOSAL: Fully-qualified names to extend overload sets
Russell Lewis
webmaster at villagersonline.com
Fri May 9 14:34:16 PDT 2008
First, if you aren't familiar with the issue, read
http://www.digitalmars.com/d/2.0/function.html#overload-sets . As has
been discussed before in the NG, we have the concept of overload sets
because we don't want 2 modules which accidentally use the same function
names to end up confusing each other's overload rules. (Similarly, we
have the problem with classes...if you define a function that shares a
name with some deeply-buried class in a library, are you overloading the
function, or accidentally defining a coincidence?)
The workaround, if you want to merge two moduless' sets, is to use
"alias" declarations in one of them. However, I think that I have a
better idea.
Let's say that a fully-qualified name (a.b.c.myFunc) functions as a
symbol which is distinct from any non-qualified name (myFunc). Now, we
can use that symbol in any *other* module to explicitly say "this new
thing that I'm defining is an overload of that other known thing."
Likewise, when you *use* the symbol, you are accessing the entire
overload set (including the add-ons). (NOTE: Since the original module
doesn't know about any of its add-ons, you are only overloading using
the things that you have defined using your imports. See example below.)
EXAMPLE CODE (PROPOSED SYNTAX)
"a.d"
int myFunc(int);
"b.d"
import a;
int a.myFunc(char);
"c.d"
import a;
a.myFunc('x'); // calls a.myFunc(int)
"d.d"
import a;
import b;
a.myFunc('x'); // calls b.myFunc(char)
END CODE
Advantages:
* Import any new module and add overloads to an *old* overload set
* Access the entire overload set (including add-ons) with the name of
the root. Think about the canonical example of a "Shape" class...
* Easily handles the case where you have 2 add-on modules to the same
base module (hard to do with 'alias').
CLASSES
This has immediate applicability to classes. An easy syntax for
overloading would be to reference the (original) base class or interface
where the overloaded-function was defined. If you don't provide that
name, then D would assume that this is a new, unrelated function.
(Question: How would we handle the gradual transition to this model?)
EXAMPLE CODE (PROPOSED)
library.d:
class A
{
int foo();
}
class B : A
{
int A.foo(); // overloads A.foo
}
myProgram.d:
import library;
class C : B
{
int foo(); // UNRELATED to A.foo!
}
A myVar = new C;
myVar.foo(); // calls B.foo()
C myVar_C = cast(C)myVar;
myVar.foo(); // calls C.foo()
THOUGHTS?
More information about the Digitalmars-d
mailing list