www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Abstract Classes vs Interfaces

reply Justin Johansson <no spam.com> writes:
Currently I'm struggling with unifying some C++ and Java code with
the idea that I might eventually port it to D2.

C++ people will know that their language supports abstract classes
and multiple inheritance but not interfaces per se (although they
can be hacked as abstract classes with implicit/trivial constructors).

Java people will know that their language also supports abstract
classes and interfaces though not multiple inheritance.

In respect of the support of abstract classes, multiple inheritance
and interfaces, both D1 and D2 are closer to Java than C++.

May I please ask of this group their opinions as to the difference
between abstract classes and interfaces from an axiomatic viewpoint.

Is there a difference axiomatically, semantically or otherwise?

Thanks in advance for all comments,

Justin Johansson
Jul 07 2010
next sibling parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 07 Jul 2010 07:24:15 -0400, Justin Johansson <no spam.com> wrote:


 Currently I'm struggling with unifying some C++ and Java code with
 the idea that I might eventually port it to D2.

 C++ people will know that their language supports abstract classes
 and multiple inheritance but not interfaces per se (although they
 can be hacked as abstract classes with implicit/trivial constructors).

 Java people will know that their language also supports abstract
 classes and interfaces though not multiple inheritance.

 In respect of the support of abstract classes, multiple inheritance
 and interfaces, both D1 and D2 are closer to Java than C++.

 May I please ask of this group their opinions as to the difference
 between abstract classes and interfaces from an axiomatic viewpoint.

 Is there a difference axiomatically, semantically or otherwise?

 Thanks in advance for all comments,

 Justin Johansson


Axiomatically, an interface can be thought of an abstract class without  
any field or method definitions. In D2, interfaces now support contracts  
and static/final methods. The real issues is that there are a host of well  
known multiple-inheritance problems with abstract classes once you move  
beyond virtual function (i.e. beyond interfaces). For example, It seems  
that D2's interface functions have inherited some of these issues.  
Consider the following:

interface A { final void foobar() { writeln("A"); } }
interface B { final void foobar() { writeln("B"); } }

class C : A, B {}

void main(string[] args) {

     C c = new C;
     c.foobar;

}

What does foobar print?
(This has been filed as bug 4435:  
http://d.puremagic.com/issues/show_bug.cgi?id=4435)
Jul 07 2010
parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
 Consider the following:
 
 interface A { final void foobar() { writeln("A"); } }
 interface B { final void foobar() { writeln("B"); } }
 
 class C : A, B {}
 
 void main(string[] args) {
 
      C c = new C;
      c.foobar;
 
 }
 
 What does foobar print?
 (This has been filed as bug 4435:
 http://d.puremagic.com/issues/show_bug.cgi?id=4435)


I believe that per TDPL, you would have to call these with eithe c.A.foobar()
or 
c.B.foobar() but that c.foobar() is not allowed. If it is allowed at present, 
it's definitely a bug. However, it's a bug in the implementation rather than
the 
language spec.

- Jonathan M Davis
Jul 07 2010
parent reply "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 07 Jul 2010 13:36:16 -0400, Jonathan M Davis  
<jmdavisprog gmail.com> wrote:


 Consider the following:

 interface A { final void foobar() { writeln("A"); } }
 interface B { final void foobar() { writeln("B"); } }

 class C : A, B {}

 void main(string[] args) {

      C c = new C;
      c.foobar;

 }

 What does foobar print?
 (This has been filed as bug 4435:
 http://d.puremagic.com/issues/show_bug.cgi?id=4435)


 I believe that per TDPL, you would have to call these with eithe  
 c.A.foobar() or
 c.B.foobar() but that c.foobar() is not allowed. If it is allowed at  
 present,
 it's definitely a bug. However, it's a bug in the implementation rather  
 than the
 language spec.

 - Jonathan M Davis


TDPL Page 215-216, mentions function hijacking of a final function by the  
implementor, which is listed as an error and detected correctly. Function  
hijacking of static functions by the implementor is not handled correctly.  
It also specifically mentions that c.A.foobar() is not the correct, nor  
ideal syntax. Indeed, it doesn't currently compile.
Jul 07 2010
next sibling parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 07 Jul 2010 14:38:09 -0400, Robert Jacques <sandford jhu.edu>  
wrote:

 On Wed, 07 Jul 2010 13:36:16 -0400, Jonathan M Davis  
 <jmdavisprog gmail.com> wrote:


 Consider the following:

 interface A { final void foobar() { writeln("A"); } }
 interface B { final void foobar() { writeln("B"); } }

 class C : A, B {}

 void main(string[] args) {

      C c = new C;
      c.foobar;

 }

 What does foobar print?
 (This has been filed as bug 4435:
 http://d.puremagic.com/issues/show_bug.cgi?id=4435)


 I believe that per TDPL, you would have to call these with eithe  
 c.A.foobar() or
 c.B.foobar() but that c.foobar() is not allowed. If it is allowed at  
 present,
 it's definitely a bug. However, it's a bug in the implementation rather  
 than the
 language spec.

 - Jonathan M Davis


 TDPL Page 215-216, mentions function hijacking of a final function by  
 the implementor, which is listed as an error and detected correctly.  
 Function hijacking of static functions by the implementor is not handled  
 correctly. It also specifically mentions that c.A.foobar() is not the  
 correct, nor ideal syntax. Indeed, it doesn't currently compile.


Since I forgot to mention it, c.foobar is the correct syntax.
Jul 07 2010
prev sibling parent reply Jonathan M Davis <jmdavisprog gmail.com> writes:
On Wednesday, July 07, 2010 11:38:09 Robert Jacques wrote:

 On Wed, 07 Jul 2010 13:36:16 -0400, Jonathan M Davis
 
 <jmdavisprog gmail.com> wrote:

 Consider the following:
 
 interface A { final void foobar() { writeln("A"); } }
 interface B { final void foobar() { writeln("B"); } }
 
 class C : A, B {}
 
 void main(string[] args) {
 
      C c = new C;
      c.foobar;
 
 }
 
 What does foobar print?
 (This has been filed as bug 4435:
 http://d.puremagic.com/issues/show_bug.cgi?id=4435)


 
 I believe that per TDPL, you would have to call these with eithe
 c.A.foobar() or
 c.B.foobar() but that c.foobar() is not allowed. If it is allowed at
 present,
 it's definitely a bug. However, it's a bug in the implementation rather
 than the
 language spec.
 
 - Jonathan M Davis


 
 TDPL Page 215-216, mentions function hijacking of a final function by the
 implementor, which is listed as an error and detected correctly. Function
 hijacking of static functions by the implementor is not handled correctly.
 It also specifically mentions that c.A.foobar() is not the correct, nor
 ideal syntax. Indeed, it doesn't currently compile.


That's talking about private final functions in an interface. Read section
6.9.3 
on pages 217 - 218.

1. If you have a method x() which is in two different interfaces and non-final
in 
both, then when a class implements both interfaces, it's single method x() 
implements both interfaces x() method simultaneously.

interface A { void x(); }
interface B { void x(); }

class C : A, B { void x() { /* implements both */ } }

void main()
{
    C c = new C();
    c.x(); // called like this
}


2. If you have a method x() which is two different interfaces and final in
both, 
then you can't implement x() in a class which implements both interfaces. You 
also can't call it like c.x() because the compiler wouldn't know which to call. 
You have to specify which interface it's being called for.

interface A { final void x() { /*do something*/ }
interface B { final void x() { /*do something else*/; }

class C : A, B { /* cannot implement x()*/ }

void main()
{
    C c = new C();
    c.A.x(); // called like this to get A's version
    c.B.x(); // called like this to get B's version
}


3. The third case is when the method is final in one interface and not in the 
other. TDPL doesn't say what happens in this case. C wouldn't be able to 
implement x() because it would be final in one of the interfaces, but I'm not 
sure if that means the other interface's x() would be used in that case or if 
you couldn't implement both interfaces together. My guess is the latter, but 
TDPL doesn't say.

interface A { final void x() { /*do something*/ }
interface B { void x(); }

class C : A, B { /* Is it legal to implement both interfaces in this case? */ }


I don't know what exactly dmd does in all cases at this point, but TDPL is
quite 
clear that if a class implements two interfaces that both have a final method 
with the same name, then if you're calling that method using the class, you
have 
to specify which interface's method you're calling.

- Jonathan M Davis
Jul 07 2010
parent "Robert Jacques" <sandford jhu.edu> writes:
On Wed, 07 Jul 2010 17:07:39 -0400, Jonathan M Davis  
<jmdavisprog gmail.com> wrote:


 On Wednesday, July 07, 2010 11:38:09 Robert Jacques wrote:

 On Wed, 07 Jul 2010 13:36:16 -0400, Jonathan M Davis

 <jmdavisprog gmail.com> wrote:

 Consider the following:

 interface A { final void foobar() { writeln("A"); } }
 interface B { final void foobar() { writeln("B"); } }

 class C : A, B {}

 void main(string[] args) {

      C c = new C;
      c.foobar;

 }

 What does foobar print?
 (This has been filed as bug 4435:
 http://d.puremagic.com/issues/show_bug.cgi?id=4435)


 I believe that per TDPL, you would have to call these with eithe
 c.A.foobar() or
 c.B.foobar() but that c.foobar() is not allowed. If it is allowed at
 present,
 it's definitely a bug. However, it's a bug in the implementation  


 rather

 than the
 language spec.

 - Jonathan M Davis


 TDPL Page 215-216, mentions function hijacking of a final function by  
 the
 implementor, which is listed as an error and detected correctly.  
 Function
 hijacking of static functions by the implementor is not handled  
 correctly.
 It also specifically mentions that c.A.foobar() is not the correct, nor
 ideal syntax. Indeed, it doesn't currently compile.


 That's talking about private final functions in an interface. Read  
 section 6.9.3
 on pages 217 - 218.

 1. If you have a method x() which is in two different interfaces and  
 non-final in
 both, then when a class implements both interfaces, it's single method  
 x()
 implements both interfaces x() method simultaneously.

 interface A { void x(); }
 interface B { void x(); }

 class C : A, B { void x() { /* implements both */ } }

 void main()
 {
     C c = new C();
     c.x(); // called like this
 }


 2. If you have a method x() which is two different interfaces and final  
 in both,
 then you can't implement x() in a class which implements both  
 interfaces. You
 also can't call it like c.x() because the compiler wouldn't know which  
 to call.
 You have to specify which interface it's being called for.

 interface A { final void x() { /*do something*/ }
 interface B { final void x() { /*do something else*/; }

 class C : A, B { /* cannot implement x()*/ }

 void main()
 {
     C c = new C();
     c.A.x(); // called like this to get A's version
     c.B.x(); // called like this to get B's version
 }


 3. The third case is when the method is final in one interface and not  
 in the
 other. TDPL doesn't say what happens in this case. C wouldn't be able to
 implement x() because it would be final in one of the interfaces, but  
 I'm not
 sure if that means the other interface's x() would be used in that case  
 or if
 you couldn't implement both interfaces together. My guess is the latter,  
 but
 TDPL doesn't say.

 interface A { final void x() { /*do something*/ }
 interface B { void x(); }

 class C : A, B { /* Is it legal to implement both interfaces in this  
 case? */ }


 I don't know what exactly dmd does in all cases at this point, but TDPL  
 is quite
 clear that if a class implements two interfaces that both have a final  
 method
 with the same name, then if you're calling that method using the class,  
 you have
 to specify which interface's method you're calling.

 - Jonathan M Davis


Thanks for the page numbers. (And I'm suddenly lamenting my slow reading  
of TDPL). Anyways, I think the above makes perfect sense, but none of it  
is implemented in DMD at this point.
Jul 07 2010
prev sibling parent reply Ary Borenszweig <ary esperanto.org.ar> writes:
On 07/07/2010 06:24 PM, Justin Johansson wrote:

 Currently I'm struggling with unifying some C++ and Java code with
 the idea that I might eventually port it to D2.

 C++ people will know that their language supports abstract classes
 and multiple inheritance but not interfaces per se (although they
 can be hacked as abstract classes with implicit/trivial constructors).

 Java people will know that their language also supports abstract
 classes and interfaces though not multiple inheritance.

 In respect of the support of abstract classes, multiple inheritance
 and interfaces, both D1 and D2 are closer to Java than C++.

 May I please ask of this group their opinions as to the difference
 between abstract classes and interfaces from an axiomatic viewpoint.

 Is there a difference axiomatically, semantically or otherwise?

 Thanks in advance for all comments,

 Justin Johansson


Basically an interface is a contract: if a class implement that 
interface then it provides all the methods described in the interface.

An abstract class just serves building common functionality for a set of 
classes that will inherit from it. If an abstract class provides no 
functionality at all then it might well be think of as an interface (it 
should be replaced by an interface.)

 From the other reply it seems that interfaces in D can have 
final/static methods. That kind of goes against what I just said about 
interfaces...
Jul 08 2010
next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Thu, 08 Jul 2010 07:59:08 -0400, Ary Borenszweig <ary esperanto.org.ar>  
wrote:


 On 07/07/2010 06:24 PM, Justin Johansson wrote:

 Currently I'm struggling with unifying some C++ and Java code with
 the idea that I might eventually port it to D2.

 C++ people will know that their language supports abstract classes
 and multiple inheritance but not interfaces per se (although they
 can be hacked as abstract classes with implicit/trivial constructors).

 Java people will know that their language also supports abstract
 classes and interfaces though not multiple inheritance.

 In respect of the support of abstract classes, multiple inheritance
 and interfaces, both D1 and D2 are closer to Java than C++.

 May I please ask of this group their opinions as to the difference
 between abstract classes and interfaces from an axiomatic viewpoint.

 Is there a difference axiomatically, semantically or otherwise?

 Thanks in advance for all comments,

 Justin Johansson


 Basically an interface is a contract: if a class implement that  
 interface then it provides all the methods described in the interface.

 An abstract class just serves building common functionality for a set of  
 classes that will inherit from it. If an abstract class provides no  
 functionality at all then it might well be think of as an interface (it  
 should be replaced by an interface.)

  From the other reply it seems that interfaces in D can have  
 final/static methods. That kind of goes against what I just said about  
 interfaces...


Not really, the class still does implement the required functions.  It's  
just that when some functions *always* are the same, then a final method  
makes it easier to maintain that one method.



interface I
{
    int foo(int x);
    int bar();

    // Note, implementing classes should *always* implement this as  
foo(bar());
    int foo();
}

Whereas in D, you have:

interface I
{
    int foo(int x);
    int bar();

    final int foo() { return foo(bar()); }
}

Much more elegant if you ask me...

And to clarify, the difference between an abstract class and an interface  
is not so much the function implementation, it's that an abstract class  
can have data members and an interface cannot.  The difficulty in  
implementing multiple inheritance is directly related to data members.   
The problem is, class inheritance is based on the axiom that a pointer to  
the base class is the same as a pointer to the derived class.  This allows  
all kinds of cool things to work with very little performance problems.   
However, if you have two base classes, then you have two *different* base  
class pointers, since the pointer to the base class must look like a  
pointer to an instance of the base class when calling the base class'  
methods.  This means casts to base classes involve changing pointers, and  
you can't simply call base functions without adding some sort of offset.   
It also makes casting to derived classes much more complex and error  
prone.  It also introduces the diamond problem (where you inherit from two  
base classes that themselves have the same base class, giving you two  
copies of the lower base class) and the horrible solution, virtual  
inheritance.

Also, multiple inheritance can be done, quite easily in D, with the new  
alias this construct.  It exposes some of the ugliness of multiple  
inheritance, but I think that's to the programmer's benefit.

-Steve
Jul 08 2010
prev sibling parent Justin Johansson <no spam.com> writes:
Ary Borenszweig wrote:

 On 07/07/2010 06:24 PM, Justin Johansson wrote:

 Currently I'm struggling with unifying some C++ and Java code with
 the idea that I might eventually port it to D2.

 C++ people will know that their language supports abstract classes
 and multiple inheritance but not interfaces per se (although they
 can be hacked as abstract classes with implicit/trivial constructors).

 Java people will know that their language also supports abstract
 classes and interfaces though not multiple inheritance.

 In respect of the support of abstract classes, multiple inheritance
 and interfaces, both D1 and D2 are closer to Java than C++.

 May I please ask of this group their opinions as to the difference
 between abstract classes and interfaces from an axiomatic viewpoint.

 Is there a difference axiomatically, semantically or otherwise?

 Thanks in advance for all comments,

 Justin Johansson





First, thanks to all respondents.


 Basically an interface is a contract: if a class implement that 
 interface then it provides all the methods described in the interface.


It's not that I don't understand interfaces and abstract classes; just
that I felt there was a underlying idea about some fundamental concept
that has hitherto been eluded.  Now I think that there is nothing else
other than that the set of all abstract classes includes the set of all
interfaces and that about it.  Abstract classes and interfaces are
simply variants of a tool for defining contractual call interfaces.
Different languages give you different features as to exactly what you
can do and cannot do with these tools.


 An abstract class just serves building common functionality for a set of 
 classes that will inherit from it. If an abstract class provides no 
 functionality at all then it might well be think of as an interface (it 
 should be replaced by an interface.)


Good point you ended with there.  Yes, I agree that the least featured
tool should be used when there is a choice of tools which are all
capable of doing the job, all other things being equal.


  From the other reply it seems that interfaces in D can have 
 final/static methods. That kind of goes against what I just said about 
 interfaces...


Yes, well, D provides implementation of these tools that might be
a little different to the concepts of these tools in other languages.
It's the abstract concept of abstract classes and interfaces which
was my main motivation in posting the question.

I think, though, from what you have said, abstract classes are
interfaces on steroids.

Worth mentioning though, that with the exception of multiple inheritance
alla C++), abstract classes in languages with single inheritance models
cannot declare classes which inherit from multiple abstract classes
Naturally, there's something tautological about this last point!

Cheers

Justin Johansson
Jul 08 2010