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.
