• Arlen Albert Keshabyan (4/4) Oct 02 2007 First, I want to say: I do not want to claim for specific features in D....
• Regan Heath (14/35) Oct 02 2007 As it stands in order to answer your question I/we require knowledge of
• Bill Baxter (8/23) Oct 02 2007 Actually there are lots of problems porting regular C++ to D. But I
• Arlen Albert Keshabyan (5/10) Oct 04 2007 ...most of the time, JUCE uses multiple inheritance to add a 'listener' ...
• Steven Schveighoffer (5/17) Oct 04 2007 Do the listener types have any implementation? If not, you can code the...
• Arlen Albert Keshabyan (3/9) Oct 04 2007 That's not true! C++ has interfaces! Even more, abstract C++ classes can...
• Steven Schveighoffer (13/29) Oct 04 2007 No, C++ does not have interfaces. It has abstract classes. Interfaces ...
• James Dennett (17/44) Oct 04 2007 Which subsume the notion of interfaces; an interface is a
• Janice Caron (13/15) Oct 05 2007 It's the other way round. Interfaces mimic abstract classes - but
• Don Clugston (10/27) Oct 05 2007 In theory multiple inheritance is a superset of interfaces. However, in ...
• Walter Bright (10/16) Oct 05 2007 I think that's a very illuminating statement. The way a language is
• James Dennett (4/22) Oct 05 2007 Just to be clear: I did *not* write that. In fact, I refuted
• Janice Caron (4/7) Oct 05 2007 Whoops! Too much cutting and pasting. My apologies. Of course it was
• Steven Schveighoffer (10/17) Oct 05 2007 Actually, it was me :)

Arlen Albert Keshabyan <arlen.albert gmail.com> writes:

First, I want to say: I do not want to claim for specific features in D. I do
not want to say good or bad words towards D language in general. I want to work
with D as it already is.

I have definite purposes and aims to port a definite library to D. But... I do
not know how to do that (no tutorial URIs, please).

Here is the GUI library I want to port to D
(http://www.rawmaterialsoftware.com/juce/). JUCE is the cross-platform
development framework written in C++ (GUI oriented). There are no problems to
port a regular C++ source code to D but... except for the one that uses
multiple inheritance. Someone here claims that multiple inheritance might be
easily emulated in D through the mixins and templates. But I see no defined way
to embody this technique into porting the library mentioned above. Please, I
need a help from anyone who can give me a descent advice on how to emulate
multiple inheritance in D effectively for my specific purposes or how to avoid
using multiple inheritance in D keeping the JUCE functionality intact.

Thank you in advance.

Regan Heath <regan netmail.co.nz> writes:

Arlen Albert Keshabyan wrote:
 First, I want to say: I do not want to claim for specific features in
 D. I do not want to say good or bad words towards D language in
 general. I want to work with D as it already is.
 
 I have definite purposes and aims to port a definite library to D.
 But... I do not know how to do that (no tutorial URIs, please).
 
 Here is the GUI library I want to port to D
 (http://www.rawmaterialsoftware.com/juce/). JUCE is the
 cross-platform development framework written in C++ (GUI oriented).
 There are no problems to port a regular C++ source code to D but...
 except for the one that uses multiple inheritance. Someone here
 claims that multiple inheritance might be easily emulated in D
 through the mixins and templates. But I see no defined way to embody
 this technique into porting the library mentioned above. Please, I
 need a help from anyone who can give me a descent advice on how to
 emulate multiple inheritance in D effectively for my specific
 purposes or how to avoid using multiple inheritance in D keeping the
 JUCE functionality intact.
 
 Thank you in advance.

As it stands in order to answer your question I/we require knowledge of 
how JUCE is designed.  So, I can't help you without investing a fair 
amount of time learning how JUCE works.  Sadly, it's unlikely I will 
find that time and therefore I wont be able to help.

I'm probably not the only one in that situation, sure there may be 
someone who already knows JUCE or is suficiently motivated to take a 
good hard look at it and get to know it, but you're better off lowering 
the bar by giving us a specific problem to solve.

So, I reckon if you took a specific piece of code from JUCE and asked 
how to solve the multiple inheritance or functionality problem in that 
piece of code you'll get many more responses.

Totally up to you of course.

Regan

Bill Baxter <dnewsgroup billbaxter.com> writes:

 I have definite purposes and aims to port a definite library to D.
 But... I do not know how to do that (no tutorial URIs, please).

 Here is the GUI library I want to port to D
 (http://www.rawmaterialsoftware.com/juce/). JUCE is the
 cross-platform development framework written in C++ (GUI oriented).

And apparently it's 150,000 lines of code!  Yikes!

 There are no problems to port a regular C++ source code to D but...
 except for the one that uses multiple inheritance. 

Actually there are lots of problems porting regular C++ to D.  But I 
won't give you a link to the page that lists many of them because you 
asked for us not to give you URIs for some reason.

 Someone here
 claims that multiple inheritance might be easily emulated in D
 through the mixins and templates. But I see no defined way to embody
 this technique into porting the library mentioned above. Please, I
 need a help from anyone who can give me a descent advice on how to
 emulate multiple inheritance in D effectively for my specific
 purposes or how to avoid using multiple inheritance in D keeping the
 JUCE functionality intact.

If you're patient enough to translate 150,000 lines of code to D then 
maybe you can be patient enough to take just a few moments to explain to 
us how JUCE uses multiple inheritance.

--bb

Arlen Albert Keshabyan <arlen.albert gmail.com> writes:

Bill Baxter Wrote:

 If you're patient enough to translate 150,000 lines of code to D then 
 maybe you can be patient enough to take just a few moments to explain to 
 us how JUCE uses multiple inheritance.
 
 --bb

...most of the time, JUCE uses multiple inheritance to add a 'listener' type to
your class. If you want to listen to any specific events then you may inherit
from several listener classes to get all that listener types within your class.
Then you may pass your class pointer to other classes that expect one of your
inherited listener type to let you receive desired events (virtual functions).

e.g. If I want to receive the Timer events, Mouse events, Keyboard events, want
to add Text flavor and some of my custom classes flavor to my new class then I
need to inherit from all that classes. Moreover, sometimes I need to use a sole
instance of the classes described above.

D templates are weak used in mixins because virtual functions with the same
names are overlaid and become inaccessible, there are no good way to
distinguish constructors and destructors in templates. D interfaces are
excessive on writing many more additional code lines to implement all functions
declared in an interface. D's abstract classes are restricted to single
inheritance too. Container classes (compositing) and interfaces are just
hell-copy-paste and hell-code-changes-concerns-all-copy-pasted-lines. D signals
are not suitable in this cases because classes can be reused solely without any
event (signal) concern (dont want to write ugly classes)...

...

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Arlen Albert Keshabyan" wrote
 Bill Baxter Wrote:

 If you're patient enough to translate 150,000 lines of code to D then
 maybe you can be patient enough to take just a few moments to explain to
 us how JUCE uses multiple inheritance.

 --bb

 ...most of the time, JUCE uses multiple inheritance to add a 'listener' 
 type to your class. If you want to listen to any specific events then you 
 may inherit from several listener classes to get all that listener types 
 within your class. Then you may pass your class pointer to other classes 
 that expect one of your inherited listener type to let you receive desired 
 events (virtual functions).

Do the listener types have any implementation?  If not, you can code them as 
interfaces, and you don't need multiple inheritance.  The JUCE project may 
have used multiple inheritance to emulate interfaces because interfaces are 
not available with C++. 

Arlen Albert Keshabyan <arlen.albert gmail.com> writes:

Steven Schveighoffer Wrote:

 Do the listener types have any implementation?  If not, you can code them as 
 interfaces, and you don't need multiple inheritance.  The JUCE project may 
 have used multiple inheritance to emulate interfaces because interfaces are 
 not available with C++. 
 
 

That's not true! C++ has interfaces! Even more, abstract C++ classes can be
used as interfaces, as abstract classes itself and as interfaces with partially
implemented factions and data.

Well yes, some JUCE listener types have some implementation. Even more,
programmers encouraged to write their own custom listeners to their own
components and there they can re-implement and reuse derived members...

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Arlen Albert Keshabyan" wrote
 Steven Schveighoffer Wrote:

 Do the listener types have any implementation?  If not, you can code them 
 as
 interfaces, and you don't need multiple inheritance.  The JUCE project 
 may
 have used multiple inheritance to emulate interfaces because interfaces 
 are
 not available with C++.

 That's not true! C++ has interfaces! Even more, abstract C++ classes can 
 be used as interfaces, as abstract classes itself and as interfaces with 
 partially implemented factions and data.

No, C++ does not have interfaces.  It has abstract classes.  Interfaces are 
not allowed to have implementations.  C++ can *mimic* interfaces with 
abstract classes that have no implementation, but the concept of an 
interface is not a language feature.  What I meant by my comment is that 
perhaps JUCE used abstract classes/multiple inheritance to mimic interfaces 
because interfaces are not supported, but I see from your comment below that 
they have some implementation.

 Well yes, some JUCE listener types have some implementation. Even more, 
 programmers encouraged to write their own custom listeners to their own 
 components and there they can re-implement and reuse derived members...

That would pose a problem.  You can somewhat mimic multiple inheritance by 
using inner classes, but generally, doing so does not directly map from C++. 
For an example of how this can work, see my post replying to Olifant on 
"Multiple Inheritance".

-Steve 

James Dennett <jdennett acm.org> writes:

Steven Schveighoffer wrote:
 "Arlen Albert Keshabyan" wrote
 Steven Schveighoffer Wrote:

 Do the listener types have any implementation?  If not, you can code them 
 as
 interfaces, and you don't need multiple inheritance.  The JUCE project 
 may
 have used multiple inheritance to emulate interfaces because interfaces 
 are
 not available with C++.

 That's not true! C++ has interfaces! Even more, abstract C++ classes can 
 be used as interfaces, as abstract classes itself and as interfaces with 
 partially implemented factions and data.

 
 No, C++ does not have interfaces. 

No, C++ does have interfaces.

 It has abstract classes. 

Which subsume the notion of interfaces; an interface is a
special case of a C++ abstract class, needing no additional
or special language support.

 Interfaces are 
 not allowed to have implementations. 

Or, to put it another way, a pure abstract base class is
also known as an "interface".  An abstract base class with
implementation details is not a pure abstract base class,
i.e., not an interface.

 C++ can *mimic* interfaces with 
 abstract classes that have no implementation, but the concept of an 
 interface is not a language feature. 

It's not mere mimicry, it's an realization of the abstract
notion of an OO "interface".

 What I meant by my comment is that 
 perhaps JUCE used abstract classes/multiple inheritance to mimic interfaces 
 because interfaces are not supported, but I see from your comment below that 
 they have some implementation.

You might have met less resistance if you'd just said that JUCE
might use MI only for interfaces, and while D doesn't support MI
in general, it has specific facilities for this special case
(which provides some of the good features of MI, while avoiding
many of the complexities).

-- James

"Janice Caron" <caron800 googlemail.com> writes:

On 10/5/07, James Dennett <jdennett acm.org> wrote:
 C++ can *mimic* interfaces with
 abstract classes that have no implementation,


It's the other way round. Interfaces mimic abstract classes - but
incompletely. Interfaces allow a workaround for the lack of multiple
inheritance, but C++ classes are without doubt the more fully featured
of the two.

Saying that C++ does not have D interfaces merely because the compiler
does not complain when you provide implementations, is like saying D
does not support C structs because the compiler does not complain when
you provide member functions.

Saying that C++ mimics interfaces because C++ can do more, is like
saying D templates *mimic* C++ templates, because D can do more.

See, what you've done there is you've taken a limitation and called it
a feature.

Don Clugston <dac nospam.com.au> writes:

Janice Caron wrote:
 On 10/5/07, James Dennett <jdennett acm.org> wrote:
 C++ can *mimic* interfaces with
 abstract classes that have no implementation,


 
 It's the other way round. Interfaces mimic abstract classes - but
 incompletely. Interfaces allow a workaround for the lack of multiple
 inheritance, but C++ classes are without doubt the more fully featured
 of the two.

In theory multiple inheritance is a superset of interfaces. However, in
practice 
there is an optimization penalty when using multiple inheritance which is not 
present with interfaces.
Hence, for example, MSVC adds __declspec(novtable) to turn an ABC into a true 
interface.

 Saying that C++ does not have D interfaces merely because the compiler
 does not complain when you provide implementations, is like saying D
 does not support C structs because the compiler does not complain when
 you provide member functions.

 Saying that C++ mimics interfaces because C++ can do more, is like
 saying D templates *mimic* C++ templates, because D can do more.
 
 See, what you've done there is you've taken a limitation and called it
 a feature.

I think that C++ does make the concept of interfaces difficult to recognize.

"Since people could put data in the base classes, they sort of felt obliged to 
do so. " -- Bjarne Stroustrup.
http://www.artima.com/intv/modern.html

Walter Bright <newshound1 digitalmars.com> writes:

Don Clugston wrote:
 I think that C++ does make the concept of interfaces difficult to 
 recognize.
 
 "Since people could put data in the base classes, they sort of felt 
 obliged to do so. " -- Bjarne Stroustrup.
 http://www.artima.com/intv/modern.html

I think that's a very illuminating statement. The way a language is 
designed strongly influences how people think about solving problems 
with it. In C++, and interface class is detectable only as a regular 
looking class with an *absence* of certain members. I don't think it is 
any surprise that it gets nearly completely overlooked.

It's like D's debug statement. Strictly speaking, it's redundant (the 
version statement could do the job instead). But what the debug 
statement does is encourage a particular style of use. That extra bit of 
recognition by the language can make all the difference.

James Dennett <jdennett acm.org> writes:

Janice Caron wrote:
 On 10/5/07, James Dennett <jdennett acm.org> wrote:
 C++ can *mimic* interfaces with
 abstract classes that have no implementation,



Just to be clear: I did *not* write that.  In fact, I refuted
it.  Please be careful with attributions!

-- James


 It's the other way round. Interfaces mimic abstract classes - but
 incompletely. Interfaces allow a workaround for the lack of multiple
 inheritance, but C++ classes are without doubt the more fully featured
 of the two.
 
 Saying that C++ does not have D interfaces merely because the compiler
 does not complain when you provide implementations, is like saying D
 does not support C structs because the compiler does not complain when
 you provide member functions.
 
 Saying that C++ mimics interfaces because C++ can do more, is like
 saying D templates *mimic* C++ templates, because D can do more.
 
 See, what you've done there is you've taken a limitation and called it
 a feature.

"Janice Caron" <caron800 googlemail.com> writes:

On 10/5/07, Janice Caron <caron800 googlemail.com> wrote:
 On 10/5/07, James Dennett <jdennett acm.org> wrote:

Whoops! Too much cutting and pasting. My apologies. Of course it was
actually Arlen Albert Keshabyan who said:

 C++ can *mimic* interfaces with
 abstract classes that have no implementation,

Again, apologies for misattribution.

"Steven Schveighoffer" <schveiguy yahoo.com> writes:

"Janice Caron" wrote
 On 10/5/07, Janice Caron <caron800 googlemail.com> wrote:
 On 10/5/07, James Dennett <jdennett acm.org> wrote:

 Whoops! Too much cutting and pasting. My apologies. Of course it was
 actually Arlen Albert Keshabyan who said:

 C++ can *mimic* interfaces with
 abstract classes that have no implementation,

 Again, apologies for misattribution.

Actually, it was me :)

My personal experience with multiple inheritance is that it sucks.  Any 
library I've dealt with that uses multiple inheritance in C++ is a library 
that I have stopped using.  My experience with interfaces is that they are 
much easier to understand and implement.  My opinion is that C++'s multiple 
inheritance is far inferior to the interface concept.  These are my 
opinions, take it or leave it.

I'm tired of this argument and shan't be posting to this thread again.

-Steve