aliasing base methods

Nicolai Waniek no.spam at thank.you
Sun Feb 25 13:17:45 PST 2007


votes++

I'd really like to have it the way you propose. Every time you override
a method, you should definitely have to write override so anyone
actually knows what you're doing. In teams it's too often that you have
to have a look at someone else's code and it's very useful to know which
method is overridden and which not.

To the interface part:
I'm used to Delphi but didn't use interfaces in D yet, so I'm kind of
shocked to get to know that your little example won't work... I think of
an interface of a kind of contract - the interface defines some methods
and the object implementing the interface provides the method in a way
the interface does not have to know of (why should it?) - just that the
object _has_ this method. This means, if a base class of your object
implements the method, the interface should use this method. Well,
there's another problem: What if your base class has a method that looks
exactly the same an interface declares a method - so both collide (read
the comment in "MyRealObject" for a better explanation)


interface ISomeInterface
{
    int thisMethod();
}

class MyBaseObject
{
    int thisMethod() {
        return 123;
    }
}

class MyRealObject : MyBaseObject, ISomeInterface
{
    // as you're not the author of MyBaseObject, you may not change
    // MyBaseObject's thisMethod to something else, or you just can't
    // change the method because it is used elsewhere, and so on.
    // You still want to provide MyBaseObject's implementation
    // Then you've got the following problem:
    //
    //  * you want to provide ISomeInterface.thisMethod
    //  * you want to provide (not override) MyBaseObject.thisMethod
    //

    // if the declaration that you implement ISomeInterface means that
    // the compiler looks into superclasses, simply leaving the method
    // out (because you inherit it) will conflict with your first point

    // the following will conflict with the second point because
    //
    // MyRealObject obj = new MyRealObject();
    // obj.thisMethod();
    //
    // will return 321 instead of 123
    //
    override int thisMethod()
    {
        return 321;
    }

    // you need to tell the compiler which method implements the
    // interface's thisMethod. In Delphi, you may do this with the
    // "implements" keyword, but I don't think this will fit into the
    // D language. consider the next few examples: which one do you more
    // like?

    // first one: delphi style
    int someMethod() implements ISomeInterface.thisMethod
    {
        return 321;
    }

    // second one, perhaps more D-ish
    int someMethod() : ISomeInterface.thisMethod
    {
        return 321;
    }
}


Perhaps another example will show where the problem may occur, too: If
you have to implement two interfaces that have two methods that are
looking the same but have to return different values:

IFirstInterface
{
    char[] getInterfaceName(); // shall return "IFirstInterface"
}

ISecondInterface
{
    char[] getInterfaceName(); // shall return "ISecondInterface"
}

class MyObject : IFirstInterface, ISecondInterface
{
    char[] getInterfaceName()
    {
        return "so what?";
    }
}

At the moment, it is not possible to solve this problem in D.

I don't know if something like that is possible at the moment, but if
you have this kind of "delegating an interface function", you could even
delegate the implementation of an interface to another object:

class MyObject : IFirstInterface
{
    MyOtherObject obj : IFirstInterface;
}

This would mean that not MyObject implements IFirstInterface but
MyOtherObject (well, that would be real information hiding *g*).


best regards,
Nicolai



More information about the Digitalmars-d mailing list