www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Need encouraging...

reply 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.
Oct 02 2007
next sibling parent 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
Oct 02 2007
prev sibling parent reply 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
Oct 02 2007
parent reply 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)... ...
Oct 04 2007
parent reply "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++.
Oct 04 2007
parent reply 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...
Oct 04 2007
parent reply "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
Oct 04 2007
parent reply 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
Oct 04 2007
next sibling parent reply "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.
Oct 05 2007
next sibling parent reply 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
Oct 05 2007
parent 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.
Oct 05 2007
prev sibling parent 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.
Oct 05 2007
prev sibling parent reply "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.
Oct 05 2007
parent "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
Oct 05 2007