Digital Mars - digitalmars.D - aliasing base methods

↑ ↓ ← → "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

Why do we really need this strange overloading, reimplementation rules.
It is so annoying.

If you overload a method from a base class you hide the base method. To
avoid this you need to do an alias.
alias Base.fnc fnc;

If more than one version of fnc exists, you cannot specify which one
shall be alias.

There is no advantage in this. Without this rule, you can probably
overload instead of the intended override (But we already have the
override keyword, make it required?). With this rule, you probably hide
an existing base implementation and probably change the behaviour of the
class, if the overloaded function is compatible to the base version.
(e.g. visitor pattern).

Another pain point: Why do we really need to reimplement a method if an
interface is again used?
interface I{ void fnc(); }
class B : I { void fnc(){} }
class C : B, I { } // error needs to reimplement fnc.

Feb 25 2007

↑ ↓ ← → Frits van Bommel <fvbommel REMwOVExCAPSs.nl> writes:

Frank Benoit (keinfarbton) wrote:
 Why do we really need this strange overloading, reimplementation rules.
 It is so annoying.

 If you overload a method from a base class you hide the base method. To
 avoid this you need to do an alias.
 alias Base.fnc fnc;


It can be a bit annoying at times, yes.

 If more than one version of fnc exists, you cannot specify which one
 shall be alias.


If you aliased an overloaded function or method name, you alias *all* 
the overloaded versions:
---
urxae urxae:~/tmp$ cat test.d
import std.stdio;

class Base {
     void foo(int) { writefln("foo(int)"); }
     void foo(char[]) { writefln("foo(char[])"); }
}

class Derived : Base {
     void foo(float) { writefln("foo(float)"); }
     alias Base.foo foo;
}

void main(){
     Derived d = new Derived;
     d.foo(1);
     d.foo("bar");
     d.foo(1.0);
}
urxae urxae:~/tmp$ dmd -run test.d
foo(int)
foo(char[])
foo(float)
---

Judging by your views on the rest of this matter, I think you will agree 
that this is usually what you want to do.

However, this seems to be another manifestation of the inability to 
specify specific overloads that is also so annoying when trying to take 
a function pointer (or in this case delegate) of an overloaded 
function/method.
A syntax for this has been proposed (e.g. &d.foo(int)) but I don't 
recall Walter responding to it. (If he did, it probably wasn't 
positively or I would have remembered)

 There is no advantage in this. Without this rule, you can probably
 overload instead of the intended override (But we already have the
 override keyword, make it required?). With this rule, you probably hide
 an existing base implementation and probably change the behaviour of the
 class, if the overloaded function is compatible to the base version.
 (e.g. visitor pattern).



 Another pain point: Why do we really need to reimplement a method if an
 interface is again used?
 interface I{ void fnc(); }
 class B : I { void fnc(){} }
 class C : B, I { } // error needs to reimplement fnc.


I can understand this one, actually. The way I see it, the only reason 
to reimplement an interface is to make sure it remains implemented even 
if the base class is modified. So the only way to keep it compiling if 
the interface is removed from the base class is to ensure you provide 
implementations.
On the other hand, an argument could be made that compile-time errors 
("interface method not implemented: 'I.fnc'") would be appropriate in 
this case...

Feb 25 2007

↑ ↓ ← → Johan Granberg <lijat.meREM OVE.gmail.com> writes:

Frank Benoit (keinfarbton) wrote:

 
 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.
 
 I propose:
 1.) make an overload not hide base implementations


votes++

 2.) make the override keyword required, to make it useful.


Not so sure about this one. It will introduce a lot of unnecessary typing
and that can be annoying if you want the function prototypes to fit into 80
characters. 

 3.) remove the interface reimplementation rule.


Definitely a good idea.

 
 What do you think?

Feb 25 2007

↑ ↓ ← → "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

 2.) make the override keyword required, to make it useful.


 Not so sure about this one. It will introduce a lot of unnecessary typing
 and that can be annoying if you want the function prototypes to fit into 80
 characters. 


I think in any bigger software, the keyword override should be used
consequently. It makes sure that a typo doesn't makes an overload
instead of an override and vice versa. Which is a bug, very hard to find.

But actually this works only in one direction (1) and it cannot be enforced.

(1) Only in one direction means, you can make sure your override is an
override, but you cannot make sure your overload is an overload. If
"override" would be required, this check works in both directions. (no
"override" means, its a not an override)

Another advantage is, in big programs, classes with many methods. You
can be sure that a overridden method is marked as such. That make
understanding of code easier.

I think every good editor can assist here very good and I believe, the
benefit of an explicit "override" is higher than the cost of
typing/autocompleting it.

Feb 25 2007

↑ ↓ ← → Johan Granberg <lijat.meREM OVE.gmail.com> writes:

Frank Benoit (keinfarbton) wrote:

 
 2.) make the override keyword required, to make it useful.


 Not so sure about this one. It will introduce a lot of unnecessary typing
 and that can be annoying if you want the function prototypes to fit into
 80 characters.


 I think in any bigger software, the keyword override should be used
 consequently. It makes sure that a typo doesn't makes an overload
 instead of an override and vice versa. Which is a bug, very hard to find.
 
 But actually this works only in one direction (1) and it cannot be
 enforced.
 
 (1) Only in one direction means, you can make sure your override is an
 override, but you cannot make sure your overload is an overload. If
 "override" would be required, this check works in both directions. (no
 "override" means, its a not an override)
 
 Another advantage is, in big programs, classes with many methods. You
 can be sure that a overridden method is marked as such. That make
 understanding of code easier.
 
 I think every good editor can assist here very good and I believe, the
 benefit of an explicit "override" is higher than the cost of
 typing/autocompleting it.


I'm more concerned about redability when the lines get to long than typing.
And I also don't think that enforcement of overload/override is that
important, no other language I have used does this and if a class have so
many methods that they cant be kept track of is probably missdesigned.

Feb 25 2007

↑ ↓ ← → Lars Ivar Igesund <larsivar igesund.net> writes:

Johan Granberg wrote:

 Frank Benoit (keinfarbton) wrote:
 
 
 2.) make the override keyword required, to make it useful.


 Not so sure about this one. It will introduce a lot of unnecessary
 typing and that can be annoying if you want the function prototypes to
 fit into 80 characters.


 I think in any bigger software, the keyword override should be used
 consequently. It makes sure that a typo doesn't makes an overload
 instead of an override and vice versa. Which is a bug, very hard to find.
 
 But actually this works only in one direction (1) and it cannot be
 enforced.
 
 (1) Only in one direction means, you can make sure your override is an
 override, but you cannot make sure your overload is an overload. If
 "override" would be required, this check works in both directions. (no
 "override" means, its a not an override)
 
 Another advantage is, in big programs, classes with many methods. You
 can be sure that a overridden method is marked as such. That make
 understanding of code easier.
 
 I think every good editor can assist here very good and I believe, the
 benefit of an explicit "override" is higher than the cost of
 typing/autocompleting it.


 I'm more concerned about redability when the lines get to long than
 typing. And I also don't think that enforcement of overload/override is
 that important, no other language I have used does this and if a class
 have so many methods that they cant be kept track of is probably
 missdesigned.


That no other language you've used has it is hardly a good reason. It isn't
to keep track of said methods, but to bind them to a contract that can be
enforced like interfaces, DbC and unittests.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Feb 25 2007

↑ ↓ ← → Bill Baxter <dnewsgroup billbaxter.com> writes:

Johan Granberg wrote:
 Frank Benoit (keinfarbton) wrote:
 


 I'm more concerned about redability when the lines get to long than typing.


public override
int some_method_with_a_long_name(and with, lots of, parameters too);

??

 And I also don't think that enforcement of overload/override is that
 important, no other language I have used does this and if a class have so
 many methods that they cant be kept track of is probably missdesigned. 


I don't think it's so much a matter of having too many methods to keep 
track of, but just not realizing there's a method there you're 
shadowing, or accidentally getting the argument types slightly wrong.

--bb

Feb 25 2007

↑ ↓ ← → Lars Ivar Igesund <larsivar igesund.net> writes:

Frank Benoit (keinfarbton) wrote:

 
 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.
 
 I propose:
 1.) make an overload not hide base implementations
 2.) make the override keyword required, to make it useful.
 3.) remove the interface reimplementation rule.
 
 What do you think?


I agree strongly with all 3 above. And 2) will be a unique help for any
program that are to be mantained for any amount of time. It is nothing but
an extension to the already existing contracts. Mantainable programs are
another area where D can shine, but then we need to take opportunities like
this.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

Feb 25 2007

↑ ↓ ← → Bill Baxter <dnewsgroup billbaxter.com> writes:

Lars Ivar Igesund wrote:
 Frank Benoit (keinfarbton) wrote:
 
 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.

 I propose:
 1.) make an overload not hide base implementations




What does this mean when combined with number 2?

class Base
{
    int foo(int) { ... }
}
class Derived : Base
{
    // Is this "error: override keyword required"
    // Or is it ok -- not an override but a distict overload leaving
    // foo(int) in tact.
    int foo(float) { ... }
}

If the above code requires 'override' then the meaning of 'override' is 
getting stretched too far.  I that case it isn't overriding anything.

If the above code is OK as is, then that's also a problem because one of 
the most common bugs with overriding is getting the signature wrong.  I 
guess if override is required for actual overriding that means the above 
coder was actually making two mistakes -- forgetting to say 'override' 
*and* getting the signature wrong, but I don't think that combination of 
mistakes would be terribly uncommon.

In short, the above code looks like it's probably a coder error and the 
coder meant to override foo(int).  But you can't be sure.

 2.) make the override keyword required, to make it useful.




+1

But note above about not playing nice with exposed base implementations. 
  If overloaded base implementations were not automatically inherited 
then the above would actually give a useful error because foo(float) is 
hiding (and thereby overriding) foo(int), though it is not declared 
'override'.

 3.) remove the interface reimplementation rule.




That sounds ok to me -- actually my naive expectation was that that was 
how interfaces already worked.

--bb

Feb 25 2007

↑ ↓ ← → "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

 
 class Base
 {
    int foo(int) { ... }
 }
 class Derived : Base
 {
    // Is this "error: override keyword required"
    // Or is it ok -- not an override but a distict overload leaving
    // foo(int) in tact.
    int foo(float) { ... }
 }
 


In this case it would compile without error. You did not provide
'override', so you say: make overload.

If 'override' is required, it would be obvious, that it is missing. So I
think it would be much easier to find this error (if override was
meant). And it is documented for a later reader. This is an improvement
of readability.

Feb 25 2007

↑ ↓ ← → Bill Baxter <dnewsgroup billbaxter.com> writes:

Frank Benoit (keinfarbton) wrote:
 class Base
 {
    int foo(int) { ... }
 }
 class Derived : Base
 {
    // Is this "error: override keyword required"
    // Or is it ok -- not an override but a distict overload leaving
    // foo(int) in tact.
    int foo(float) { ... }
 }


 In this case it would compile without error. You did not provide
 'override', so you say: make overload.
 
 If 'override' is required, it would be obvious, that it is missing. 


I'm not so sure.  I try to live by the 'mark all overrides' policy 
myself but still I often forget.

 So I
 think it would be much easier to find this error (if override was
 meant). And it is documented for a later reader. This is an improvement
 of readability.


Any improvement of readability comes from 2) -- making 'override' 
required.  Not from 1) -- making all overloads propagate.  1) saves 
typing but does not necessarily improve readability.  What could be more 
clear than an explicit list of all the base class versions of foo()?

Also -- does this() get special treatment?  Or do constructors all 
automatically propagate too?

And in general how do I hide super.foo(int) if I _don't_ want it? 
(private assert(0) re-implementation of every method I don't want perhaps?)

I guess I would be happier with something that required explicitly 
declaring that base class overloads should be forwarded.  Like
    alias super.foo foo;  // bring forward all base class foo's
or
    alias super.foo(int) foo; // bring forward only the int version.


Another thought -- making override required could make life difficult 
for some code generators.  Imagine an automatic class wrapper that 
creates a derived class of the form:

class foo(Base)  : Base
{
    int someMethod(int x) { ... }
}

That will always work now, but if override becomes required, then that 
template will have to do some static if mojo to figure out if Base 
already has a someMethod(int) implemented or not and if so stick in the 
'override'.

--bb

Feb 25 2007

↑ ↓ ← → "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

 Another thought -- making override required could make life difficult
 for some code generators.  Imagine an automatic class wrapper that
 creates a derived class of the form:
 
 class foo(Base)  : Base
 {
    int someMethod(int x) { ... }
 }
 
 That will always work now, but if override becomes required, then that
 template will have to do some static if mojo to figure out if Base
 already has a someMethod(int) implemented or not and if so stick in the
 'override'.


No, it will not work.
Today you also need to know the base class methods, and add aliases in
you generated class, if needed. The problem is exactly the same. TioPort
actually implements this.

For generated code, it is probably easier this way with override.
Because if you generate code, you most of the time know, that you do a
override.

To the ambiguity issue of the alias:
Override is always/already precise, because it *is* bundled with the
complete method signature.

Feb 25 2007

↑ ↓ ← → Bill Baxter <dnewsgroup billbaxter.com> writes:

Frank Benoit (keinfarbton) wrote:
 Another thought -- making override required could make life difficult
 for some code generators.  Imagine an automatic class wrapper that
 creates a derived class of the form:

 class foo(Base)  : Base
 {
    int someMethod(int x) { ... }
 }

 That will always work now, but if override becomes required, then that
 template will have to do some static if mojo to figure out if Base
 already has a someMethod(int) implemented or not and if so stick in the
 'override'.


 No, it will not work.
 Today you also need to know the base class methods, and add aliases in
 you generated class, if needed. 
 The problem is exactly the same. TioPort
 actually implements this.


Good point.

 For generated code, it is probably easier this way with override.
 Because if you generate code, you most of the time know, that you do a
 override.


Not necessarily.  The foo(Base) class could be trying to apply a uniform 
interface to something, and not care whether base class methods are 
being reimplemented/hidden or not.  This is more or less the case with 
policy-based design.  http://en.wikipedia.org/wiki/Policy-based_design
The policy implementers just need to have the methods required by the 
policy, but they could also have other methods too.  The interface in 
the end, though, is supposed to be what the base class presents to the 
world, and you don't generally care if you're hiding methods or not.
(Of course Policy based design is not as useful in D because there's no 
multiple inheritance -- maybe Andrei can comment more on alternatives ;-) )

 To the ambiguity issue of the alias:
 Override is always/already precise, because it *is* bundled with the
 complete method signature.


Don't follow you there.

--bb

Feb 26 2007

↑ ↓ ← → "Frank Benoit (keinfarbton)" <benoit tionex.removethispart.de> writes:

 To the ambiguity issue of the alias:
 Override is always/already precise, because it *is* bundled with the
 complete method signature.


 Don't follow you there.


My point was, that the alias is actually not precise, but the override
already is.

If you alias a method, it can be ambiguous, because you do not specify
which version you want to alias. You would need to extend the syntax to
make is precise.

alias Base.fnc fnc;      // all fnc (not precise)
alias Base.fnc(int) fnc; // exactly this fnc. (precise)

In the opposite, the override keyword is already precise, because it is
the method signature.

override void fnc( float ){ ... }

No change in syntax needed.

Feb 26 2007

↑ ↓ ← → Bill Baxter <dnewsgroup billbaxter.com> writes:

Frank Benoit (keinfarbton) wrote:
 To the ambiguity issue of the alias:
 Override is always/already precise, because it *is* bundled with the
 complete method signature.




 My point was, that the alias is actually not precise, but the override
 already is.
 
 If you alias a method, it can be ambiguous, because you do not specify
 which version you want to alias. You would need to extend the syntax to
 make is precise.
 
 alias Base.fnc fnc;      // all fnc (not precise)
 alias Base.fnc(int) fnc; // exactly this fnc. (precise)
 
 In the opposite, the override keyword is already precise, because it is
 the method signature.
 
 override void fnc( float ){ ... }
 
 No change in syntax needed.


Ok.  I see what you mean now.  But one way or another we're going to 
have to fix the alias mess.  Not being able to alias a particular 
version of an overloaded function is just too much of a gaping hole.

--bb

Feb 26 2007

↑ ↓ ← → Ary Manzana <ary esperanto.org.ar> writes:

Frank Benoit (keinfarbton) escribi�:
 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.
 
 I propose:
 1.) make an overload not hide base implementations
 2.) make the override keyword required, to make it useful.
 3.) remove the interface reimplementation rule.
 
 What do you think?


I also agree with the three points.

Number 2 is especially useful if a function in a base class is removed. 
Inmediately you can tell which classes need to remove the overriden 
functions because they are no longer in use, and can lead to bugs.

Feb 25 2007

↑ ↓ ← → Bill Baxter <dnewsgroup billbaxter.com> writes:

Ary Manzana wrote:
 Frank Benoit (keinfarbton) escribi�:
 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.

 I propose:
 1.) make an overload not hide base implementations
 2.) make the override keyword required, to make it useful.
 3.) remove the interface reimplementation rule.

 What do you think?


 I also agree with the three points.
 
 Number 2 is especially useful if a function in a base class is removed. 
 Inmediately you can tell which classes need to remove the overriden 
 functions because they are no longer in use, and can lead to bugs.


Already works that way if you just use override religiously.

--bb

Feb 25 2007

↑ ↓ ← → Ary Manzana <ary esperanto.org.ar> writes:

Bill Baxter escribi�:
 Ary Manzana wrote:
 Frank Benoit (keinfarbton) escribi�:
 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.

 I propose:
 1.) make an overload not hide base implementations
 2.) make the override keyword required, to make it useful.
 3.) remove the interface reimplementation rule.

 What do you think?


 I also agree with the three points.

 Number 2 is especially useful if a function in a base class is 
 removed. Inmediately you can tell which classes need to remove the 
 overriden functions because they are no longer in use, and can lead to 
 bugs.


 Already works that way if you just use override religiously.
 
 --bb


But who in this days believe in programmers? :-P

Feb 25 2007

↑ ↓ ← → "Kristian Kilpi" <kjkilpi gmail.com> writes:

On Sun, 25 Feb 2007 16:13:01 +0200, Frank Benoit (keinfarbton)  =

<benoit tionex.removethispart.de> wrote:

 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.

 I propose:
 1.) make an overload not hide base implementations
 2.) make the override keyword required, to make it useful.
 3.) remove the interface reimplementation rule.

 What do you think?



I, also, don't like that an overload or override will hide base function=
s.  =

I think
requiring the 'override' keyword would make code more readable. But what=
 if
other cases (see below) would also require explicit syntax? (I don't kno=
w  =

what
the full implications of this would be, etc; just some quick thoughts.)


Ok, there are the following five cases:

1) Define a new function (i.e. the base class doesn't have one with the =
 =

same name).

2a) Override a function; don't hide other functions with the same name.
2b) Override a function; hide other functions with the same name.

3a) Add an overload for a function; don't hide other functions with the =
 =

same name.
3b) Add an overload for a function; hide other functions with the same  =

name.

(I think I haven't ever wanted/needed to use the cases 2b and 3b, though=
,  =

but I guess
that's just me.)


New rules would be:

A) The 'override' keyword is required for the case 2a.

B) A new keyword 'overload' is required for the case 3a. (I don't know i=
f  =

'overload'
is a right word for it because it's similar to 'override'. I use it here=
  =

though.)

C) A new keyword 'renew' (or something) is required for the cases 2b and=
  =

3b.


For example:

   class Base {
     int foo();
     int foo(int);
   }

   class Derived : Base {
     int bar();                //ok

     int foo();                //error; 'Base' has 'int foo()'
     renew int foo();          //ok (hides 'int foo(int)')

     override int foo();       //ok
     override int foo(float);  //error; 'Base' has no 'int foo(float)'

     overload int foo();       //error; 'Base' has 'int foo()'
     overload int foo(float);  //ok
   }


For templates, there should also be extra keywords to allow easy code  =

generation.
For example, <X> =3D=3D override || overload, <X> is some keyword.

Feb 26 2007

↑ ↓ ← → xs0 <xs0 xs0.com> writes:

Frank Benoit (keinfarbton) wrote:
 My point is, i want this strange rules to be removed.
 And I want the override keyword not to be a useless thing.
 
 I propose:
 1.) make an overload not hide base implementations


Definitely. Imho, hiding them achieves nothing except annoyance.. 
Though, if I recall correctly, the argument for hiding is the following 
- if the base class gets a method with the same name, users of the 
derived class will start calling the new method in some cases, most 
probably causing trouble (as the derived class now doesn't override the 
new method, even if it previously did override all other methods with 
the same name).

But, it seems that most people don't expect the hiding to happen, and 
the alias workaround just seems wrong somehow, at least to me. So, why 
not introduce some new syntax?

class Derived : Base {
     override foo; // I declare that I'll be overriding all foos

     // override no longer needed here or in other foos, even
     // if override is made mandatory
     public void foo(int i) { .. }
}

Problem solved :)


 2.) make the override keyword required, to make it useful.


+1


 3.) remove the interface reimplementation rule.


Well, it can be useful in similar cases as for 1, so why not remove 
reimplementation requirement by default, but with the option of

class NewFoo : OldFoo, override IFoo
{
    // reimplementation required
}


xs0

Feb 26 2007

↑ ↓ ← → Nicolai Waniek <no.spam thank.you> writes:

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

Feb 25 2007