Real OOP with D

Caspar via Digitalmars-d-learn digitalmars-d-learn at puremagic.com
Tue Aug 18 01:13:43 PDT 2015


On Tuesday, 18 August 2015 at 07:19:02 UTC, BBasile wrote:
> On Tuesday, 18 August 2015 at 06:27:53 UTC, Ozan wrote:
>> On Monday, 17 August 2015 at 06:59:51 UTC, BBasile wrote:
>>> On Monday, 17 August 2015 at 05:57:52 UTC, Ozan wrote:
>>>> Hi
>> [...]
>>>>
>>>> Is there any way to get real OOP with D?
>>>>
>>>> Regards,  Ozan
>>>
>>> Can you name an OOP oriented language that allows this ? Your 
>>> example is eroneous OOP.
>>> The 2 other answers you 've got (the first using an interface 
>>> and the second using an abstract class) are valid OOP.
>>>
>>> One of the fundamental concept OOP is that a function defined 
>>> in a class exists also  in its subclasses. So how do you 
>>> expect `greeting()` to exist in Family if it's only defined 
>>> in its sub-classes ?
>>>
>>> You can verify that with the 'Liskov substitution principle' 
>>> (https://en.wikipedia.org/wiki/Liskov_substitution_principle).
>>> Actually your sample violates this principle.
>>
>> Languages like Groovy or JavaScript (with the help of 
>> frameworks ;-)
>> And I believe many more the newer ones.  But that's not the 
>> point.
>>
>> And... This was not a criticism against D (... "bad D, has no 
>> understanding of OOP. Boahh"  ;-)
>> It was only a question about handling of a typical OOP problem 
>> in a class-typed implementation of OOP like D has. Thanks to 
>> every existing or new creative programming language, today we 
>> have so many other ways to solve our programming problems.
>>
>> Regards Ozan
>
> You example is not valid strongly-typed OOP. In D you could do 
> something similar but not with the OO paradigm but rather with 
> compile-time refexion (introspection):
>
> ---
> import std.stdio;
>
> static bool isFamilyMember(T)()
> {
>     import std.traits: isCallable;
>     return __traits(hasMember, T, "greeting");
> }
>
> void FamilyMemberSayHello(T)(ref T t)
> {
>     static if (isFamilyMember!T)
>         t.greeting;
> }
>
> struct Dad{
>     void greeting(){"hello from a Dad".writeln;}
> }
>
> struct Boy{
>     void greeting(){"hello from a Boy".writeln;}
> }
>
> struct IdiotDuBled{}
>
> void main()
> {
>     auto dad = new Dad;
>     auto boy = new Boy;
>     auto idiotDuBled = new IdiotDuBled;
>
>     FamilyMemberSayHello(dad);
>     FamilyMemberSayHello(boy);
>     FamilyMemberSayHello(idiotDuBled);
> }
> ---
>
> The idea is rather to check at compile time if a variable will 
> have the "trait" which characterizes a FamilyMember, without 
> using inheritence.

I believe D allows what you want to do using generic programming.
Being a compiled and strongly typed language, the information 
about the type, needs to be available during compilation, but 
this makes no difference from a theoretic OOP view.

BBasiles example can also be done without the trait. Then the 
check for greeting() will be done by the compiler.

void FamilyMemberSayHello(T)(ref T t)
{
         t.greeting;
}
struct Dad{
     void greeting(){"hello from a Dad".writeln;}
}
struct Boy{
     void greeting(){"hello from a Boy".writeln;}
}
struct IdiotDuBled{}
void main()
{
     auto dad = new Dad;
     auto boy = new Boy;
     auto idiotDuBled = new IdiotDuBled;

     FamilyMemberSayHello(dad);
     FamilyMemberSayHello(boy);
     FamilyMemberSayHello(idiotDuBled); //will not compile
}


The OOP Model of D is fairly close to that of Eiffel which I 
consider pretty pure Object Oriented. The only exception is 
multiple inheritance, which I do not miss at all.

In my Opinion D is a great language for Object Oriented Design 
and Programming.
It awesomely supports Contracts and Constraint Generics, which 
many languages lack.
I never missed multiple inheritance, as I was able to cover all 
my use cases with mixins.
The support for functional programming and CTFE allows to 
elegantly handle the cases, where inheritance based OOP feels 
awkward.
Actually I urge all the people who say: "Smalltalk was the last 
(only) good OOP language!" to try out D.


More information about the Digitalmars-d-learn mailing list