On Thu, 08 Jul 2010 07:59:08 -0400, Ary Borenszweig <[email protected]>
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.
In java/C# you have this awkward construct:
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
