Jump to page: 1 27  
Page
Thread overview
Multiple Inheritance of Classes
Aug 12, 2008
Chris R. Miller
Aug 12, 2008
Lars Ivar Igesund
Aug 12, 2008
superdan
Aug 12, 2008
BCS
Aug 12, 2008
superdan
Aug 12, 2008
BCS
Aug 12, 2008
Dee Girl
Aug 12, 2008
superdan
Aug 12, 2008
Manfred_Nowak
Aug 12, 2008
superdan
Aug 12, 2008
Robert Fraser
Aug 12, 2008
superdan
Aug 12, 2008
Yigal Chripun
Aug 12, 2008
superdan
Aug 12, 2008
superdan
Aug 13, 2008
Yigal Chripun
Aug 13, 2008
superdan
Aug 13, 2008
Yigal Chripun
Aug 14, 2008
Manfred_Nowak
Aug 14, 2008
superdan
Aug 12, 2008
Lars Ivar Igesund
Aug 13, 2008
Chris R. Miller
Aug 12, 2008
Benji Smith
Aug 13, 2008
Dee Girl
Aug 13, 2008
Christopher Wright
Aug 13, 2008
superdan
Aug 13, 2008
Denis Koroskin
Aug 13, 2008
Denis Koroskin
Aug 19, 2008
JAnderson
Aug 13, 2008
Chris R. Miller
Aug 14, 2008
Denis Koroskin
Aug 13, 2008
lurker
Aug 13, 2008
lurker
Aug 13, 2008
Denis Koroskin
Aug 13, 2008
Chris R. Miller
Aug 14, 2008
Manfred_Nowak
Aug 14, 2008
Denis Koroskin
Aug 12, 2008
Chris R. Miller
Aug 12, 2008
superdan
Aug 13, 2008
Chris R. Miller
Aug 13, 2008
Dee Girl
Aug 13, 2008
superdan
Aug 14, 2008
Dee Girl
Aug 13, 2008
Walter Bright
Aug 13, 2008
Dee Girl
Aug 13, 2008
Walter Bright
Aug 14, 2008
Dee Girl
[OT] Re: Multiple Inheritance of Classes
Aug 13, 2008
Ary Borenszweig
Aug 13, 2008
Dee Girl
Aug 13, 2008
BCS
Aug 13, 2008
Chris R. Miller
Aug 13, 2008
Christopher Wright
Aug 12, 2008
Sclytrack
Aug 13, 2008
Wyverex
Aug 14, 2008
BLS
Aug 14, 2008
Chris R. Miller
Aug 14, 2008
BLS
Aug 14, 2008
JAnderson
MI is not evil - it is just a different concept...
Dec 26, 2008
The User
Dec 26, 2008
Yigal Chripun
Dec 26, 2008
bearophile
Dec 27, 2008
Don
August 12, 2008
Understand, I'm NOT demanding ANYTHING.

What is the current state of thought about Multiple Inheritance for classes in D?  I'd like to have that feature, since it'd make some stuff I want to do a bit easier.  Is it not there because it's not worth the effort to implement?  Because it's evil and needs to die (I don't know, some people could possibly be adamantly anti-MI)?  I don't know.  I know I can add a lot with mixins, but I'd just like to know what the state of the feature is.

The reason is I was trying to explain how cool D is to some other friends of mine, and they asked about Multiple Inheritance (of classes) and they were sort of put off by it's lack of it.  Then again, he was an Objective-C programmer...  ;-)

So please don't take offense, since none is meant, I just wanted to know what I could hope for in the future.



August 12, 2008
Chris R. Miller wrote:

> Understand, I'm NOT demanding ANYTHING.
> 
> What is the current state of thought about Multiple Inheritance for classes in D?  I'd like to have that feature, since it'd make some stuff I want to do a bit easier.  Is it not there because it's not worth the effort to implement?  Because it's evil and needs to die (I don't know, some people could possibly be adamantly anti-MI)?

This is actually the reason, not the adamantly anti-MI part, just that MI is evil and that is well acknowledged almost everywhere. You will find good argumentation against it if you look, too.

> I don't know.  I know
> I can add a lot with mixins, but I'd just like to know what the state of
> the feature is.
> 
> The reason is I was trying to explain how cool D is to some other friends of mine, and they asked about Multiple Inheritance (of classes) and they were sort of put off by it's lack of it.  Then again, he was an Objective-C programmer...  ;-)

In the languages where MI is possible, it usually also is possible to not shoot your own foot with some care, in which case it can appear as a powerful feature. But almost everywhere it just is a very bad idea, and you will find it is banned in many projects for languages allowing it (like C++).

> So please don't take offense, since none is meant, I just wanted to know what I could hope for in the future.

You should hope you can redesign your application to not need MI ;)

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango
August 12, 2008
D will never support Multiple Inheritance.
It is evil and must die (from the options you gave me).
Also it is easier to memorize a tree structure than a spider web.
Well you already know the workarounds.

/me needs to use more structs over classes. They're a heck of a lot faster.



August 12, 2008
Lars Ivar Igesund Wrote:

> Chris R. Miller wrote:
> 
> > Understand, I'm NOT demanding ANYTHING.
> > 
> > What is the current state of thought about Multiple Inheritance for classes in D?  I'd like to have that feature, since it'd make some stuff I want to do a bit easier.  Is it not there because it's not worth the effort to implement?  Because it's evil and needs to die (I don't know, some people could possibly be adamantly anti-MI)?
> 
> This is actually the reason, not the adamantly anti-MI part, just that MI is evil and that is well acknowledged almost everywhere. You will find good argumentation against it if you look, too.

appeal to authority. appeal to ridicule. appeal to the majority. all in one sentence. wow. at least could you space out your fallacies a bit more.

the man has kindly asked a sensible question. he deserves a good answer. if u can't give one just don't reply. this is just ignorance.

below's an attempt at an answer.

first i repeat what is already known. d does do multiple inheritance thru interfaces. it doesn't do multiple inheritance of implementation. better put doesn't do multiple inheritance of data. why? simple. d is a fixed layout language. means that the offset of any data member within the object is known during compilation. with mi it is impossible to lay out objects in a fixed layout. unless you do it the nonsensical way c++ does. at least you can't lay out with 1-dimensional memory. (i've done vlsi design and sure as shit 2-dim helps a lot. but a lot more could be done with 3-dim. i remember only adding two layers was a huge deal.) with mi from n classes you'd need n-dimensional ram. that's why only simple inheritance is possible with 1-dimensional ram. if u want fixed layout that is. (now that i got into it there was a guy who did 2-class inheritance by storing stuff at positive and negative offsets, thus adding a 2nd dimension.) mi of interfaces is a good thing and putting an int in an interface does not make it evil. just makes it impossible to lay out.

interfaces could implement functions. that does make a lot of sense. example:

interface Customer
{
    string ssn();
    string name();
    string uniqueName() { return name ~ "(ssn: " ~ ssn ~ ")"; }
}

so uniqueName formats a specific way. a descendant can choose to change that or just use the default. no idea why walt chose to disallow that. walt?

> > I don't know.  I know
> > I can add a lot with mixins, but I'd just like to know what the state of
> > the feature is.
> > 
> > The reason is I was trying to explain how cool D is to some other friends of mine, and they asked about Multiple Inheritance (of classes) and they were sort of put off by it's lack of it.  Then again, he was an Objective-C programmer...  ;-)
> 
> In the languages where MI is possible, it usually also is possible to not shoot your own foot with some care, in which case it can appear as a powerful feature. But almost everywhere it just is a very bad idea, and you will find it is banned in many projects for languages allowing it (like C++).
> 
> > So please don't take offense, since none is meant, I just wanted to know what I could hope for in the future.
> 
> You should hope you can redesign your application to not need MI ;)
> 
> -- 
> Lars Ivar Igesund
> blog at http://larsivi.net
> DSource, #d.tango & #D: larsivi
> Dancing the Tango

"blah blah blah more contentless uninformative fallacious blabber blah i can't believe i'm still reading this blah blah". sorry dood but this is all i'm seeing.

August 12, 2008
Reply to superdan,

> Lars Ivar Igesund Wrote:
> 
>> Chris R. Miller wrote:
>> 
>>> Understand, I'm NOT demanding ANYTHING.
>>> 
>>> What is the current state of thought about Multiple Inheritance for
>>> classes in D?  I'd like to have that feature, since it'd make some
>>> stuff I want to do a bit easier.  Is it not there because it's not
>>> worth the effort to implement?  Because it's evil and needs to die
>>> (I don't know, some people could possibly be adamantly anti-MI)?
>>> 
>> This is actually the reason, not the adamantly anti-MI part, just
>> that MI is evil and that is well acknowledged almost everywhere. You
>> will find good argumentation against it if you look, too.
>> 
> appeal to authority.

Always a good idea if, like most people, you don't plan on /becoming/ an authority

> appeal to ridicule. appeal to the majority.

Both reasonable if enough people are doing the ridicule (95% majority?), again with the disclaimer for the occasional expert/academic that most of us (walter excluded) don't have anywhere near the time to become.

> the man has kindly asked a sensible question. he deserves a good
> answer. if u can't give one just don't reply. this is just ignorance.
> 

I think that was a good answer to the question "Why doesn't D have MI?"

> below's an attempt at an answer.

The below is a reasonable answer to "Justify D's lack of MI." or "What is the rational for D's not having MI?" Those are different questions that what Lars was going for.

> 
> first i repeat what is already known. d does do multiple inheritance
> thru interfaces.

Is interfaces MI? That is debatable because, as you point out, there is a huge difference between it and MI->data & MI->implementation.

> it doesn't do multiple inheritance of implementation.
> better put doesn't do multiple inheritance of data.

[...]
> putting an int in an interface does not
> make it evil. just makes it impossible to lay out.
> 

In this context "evil" is a relative term. Nothing in programing it truly evil... Well maybe C++.
http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm

> interfaces could implement functions. that does make a lot of sense.
> example:
> 
> interface Customer
> {
> string ssn();
> string name();
> string uniqueName() { return name ~ "(ssn: " ~ ssn ~ ")"; }
> }

Yeah, I've wanted that, OTOH it might get tricky to implement because of the mechanics of interfaces.

option 1: uniqueName becomes a implicit mixin that gets expanded per class 

code bloat, etc. but that's what we do manually anyway.

option 2: uniqueName has a single implementation that is shared by all implementing classes

This is an ugly solution because the only way to make that work would be to have this inside uniqueName be an interface reference, however as things stand interface references are turned into object references (by offsetting the pointer) on interface calls. Work around for this include doing this inside the functions and having an interface version and a non interface version of each function (not viable for closed source) or using little shells everywhere (errr, yuck, but it would work)

> so uniqueName formats a specific way. a descendant can choose to
> change that or just use the default. no idea why walt chose to
> disallow that. walt?
> 


August 12, 2008
superdan Wrote:
> below's an attempt at an answer.
> 
> first i repeat what is already known. d does do multiple inheritance thru interfaces. it doesn't do multiple inheritance of implementation. better put doesn't do multiple inheritance of data. why? simple. d is a fixed layout language. means that the offset of any data member within the object is known during compilation. with mi it is impossible to lay out objects in a fixed layout. unless you do it the nonsensical way c++ does. at least you can't lay out with 1-dimensional memory. (i've done vlsi design and sure as shit 2-dim helps a lot. but a lot more could be done with 3-dim. i remember only adding two layers was a huge deal.) with mi from n classes you'd need n-dimensional ram. that's why only simple inheritance is possible with 1-dimensional ram. if u want fixed layout that is. (now that i got into it there was a guy who did 2-class inheritance by storing stuff at positive and negative offsets, thus adding a 2nd dimension.) mi of interfaces is a good thing and putting an int in an interface does not make it evil. just makes it impossible to lay out.

I am impress! The above is true word with word. Without one word maybe ^_^. I did a semester project for data layout with maximum efficient. It is hard! Maybe you talk about this paper: Bidirectional Object Layout. http://citeseer.ist.psu.edu/myers95bidirectional.html There is also follow up paper: Two-Directional Bidimensional Object Layout. http://citeseer.ist.psu.edu/670868.htm Maybe you are talk about the second because it has the negative offset. Thank you, Dee Girl
August 12, 2008
Dee Girl Wrote:

> superdan Wrote:
> > below's an attempt at an answer.
> > 
> > first i repeat what is already known. d does do multiple inheritance thru interfaces. it doesn't do multiple inheritance of implementation. better put doesn't do multiple inheritance of data. why? simple. d is a fixed layout language. means that the offset of any data member within the object is known during compilation. with mi it is impossible to lay out objects in a fixed layout. unless you do it the nonsensical way c++ does. at least you can't lay out with 1-dimensional memory. (i've done vlsi design and sure as shit 2-dim helps a lot. but a lot more could be done with 3-dim. i remember only adding two layers was a huge deal.) with mi from n classes you'd need n-dimensional ram. that's why only simple inheritance is possible with 1-dimensional ram. if u want fixed layout that is. (now that i got into it there was a guy who did 2-class inheritance by storing stuff at positive and negative offsets, thus adding a 2nd dimension.) mi of interfaces is a good thing and putting an int in an interface does not make it evil. just makes it impossible to lay out.
> 
> I am impress! The above is true word with word. Without one word maybe ^_^. I did a semester project for data layout with maximum efficient. It is hard! Maybe you talk about this paper: Bidirectional Object Layout. http://citeseer.ist.psu.edu/myers95bidirectional.html There is also follow up paper: Two-Directional Bidimensional Object Layout. http://citeseer.ist.psu.edu/670868.htm Maybe you are talk about the second because it has the negative offset. Thank you, Dee Girl

cool dee. where do you pull'em from. i vaguely think i was talking about the second one, the israel dood, but then i'm just guessin' (and braggin').
August 12, 2008
BCS Wrote:

> Reply to superdan,
> 
> > Lars Ivar Igesund Wrote:
> > 
> >> Chris R. Miller wrote:
> >> 
> >>> Understand, I'm NOT demanding ANYTHING.
> >>> 
> >>> What is the current state of thought about Multiple Inheritance for classes in D?  I'd like to have that feature, since it'd make some stuff I want to do a bit easier.  Is it not there because it's not worth the effort to implement?  Because it's evil and needs to die (I don't know, some people could possibly be adamantly anti-MI)?
> >>> 
> >> This is actually the reason, not the adamantly anti-MI part, just that MI is evil and that is well acknowledged almost everywhere. You will find good argumentation against it if you look, too.
> >> 
> > appeal to authority.
> 
> Always a good idea if, like most people, you don't plan on /becoming/ an authority

hard time defending that post eh. he appealed to his own authority "this is the reason". then to an emotional word. then to majority.

see also http://en.wikipedia.org/wiki/Appeal_to_authority tho invoking wikipedia may also be a fallacy :)

> > appeal to ridicule. appeal to the majority.
> 
> Both reasonable if enough people are doing the ridicule (95% majority?), again with the disclaimer for the occasional expert/academic that most of us (walter excluded) don't have anywhere near the time to become.

i don't find either particularly reasonable. http://en.wikipedia.org/wiki/Appeal_to_ridicule
http://en.wikipedia.org/wiki/Argumentum_ad_populum. if you don't have the time to become an expert just let walter or some expert answer. that post reveals zero knowledge on the subject. merely a perpetuation of the "it's evil" heard from someone else and ingested noncritically. after "don't do it!!! it's evil!!!" all i can expect next is "keep the faith!!!" fuck man.

> > the man has kindly asked a sensible question. he deserves a good answer. if u can't give one just don't reply. this is just ignorance.
> > 
> 
> I think that was a good answer to the question "Why doesn't D have MI?"

"it's evil" is a good answer? cut the shit man. why is it evil again? your critical reasoning filter ever questioned that assertion?

> > below's an attempt at an answer.
> 
> The below is a reasonable answer to "Justify D's lack of MI." or "What is the rational for D's not having MI?" Those are different questions that what Lars was going for.

pardon me if i'm dense but i have a hard time distinguishing between the two. and pardon me if i continue to think "it's evil" is mere oxshit.

> > first i repeat what is already known. d does do multiple inheritance thru interfaces.
> 
> Is interfaces MI? That is debatable because, as you point out, there is a huge difference between it and MI->data & MI->implementation.

it's not debatable. interfaces are inheritance. they satisfy the definition. (substitution principle.) if you implement multiple interfaces you do mi. case closed. to summarize: d does mi of interface but not mi of data and not mi of implementation. they are different flavors of shit but that does not make interfaces mi debatable.

> > it doesn't do multiple inheritance of implementation. better put doesn't do multiple inheritance of data.
> 
> [...]
> > putting an int in an interface does not
> > make it evil. just makes it impossible to lay out.
> > 
> 
> In this context "evil" is a relative term. Nothing in programing it truly evil... Well maybe C++. http://www-users.cs.york.ac.uk/~susan/joke/cpp.htm
> 
> > interfaces could implement functions. that does make a lot of sense. example:
> > 
> > interface Customer
> > {
> > string ssn();
> > string name();
> > string uniqueName() { return name ~ "(ssn: " ~ ssn ~ ")"; }
> > }
> 
> Yeah, I've wanted that, OTOH it might get tricky to implement because of the mechanics of interfaces.
> 
> option 1: uniqueName becomes a implicit mixin that gets expanded per class
> 
> code bloat, etc. but that's what we do manually anyway.
> 
> option 2: uniqueName has a single implementation that is shared by all implementing classes
> 
> This is an ugly solution because the only way to make that work would be to have this inside uniqueName be an interface reference, however as things stand interface references are turned into object references (by offsetting the pointer) on interface calls. Work around for this include doing this inside the functions and having an interface version and a non interface version of each function (not viable for closed source) or using little shells everywhere (errr, yuck, but it would work)

nothing that walt can't do.
August 12, 2008
superdan wrote:

> with mi it is impossible to lay out objects in a fixed layout. unless you do it [...]

I do not understand this. Do you mean, that it is impossible or do you mean one can do a fixed layout _with_ mi?

Then: given that "D is a systems programming language", how would one implement an efficient system, for which a requirement for mi exists, in D?

-manfred


-- 
Maybe some knowledge of some types of disagreeing and their relation can turn out to be useful: http://blog.createdebate.com/2008/04/07/writing-strong-arguments/
August 12, 2008
Lars Ivar Igesund wrote:
> Chris R. Miller wrote:
>> Understand, I'm NOT demanding ANYTHING.
>>
>> What is the current state of thought about Multiple Inheritance for classes in D?  I'd like to have that feature, since it'd make some stuff I want to do a bit easier.  Is it not there because it's not worth the effort to implement?  Because it's evil and needs to die (I don't know, some people could possibly be adamantly anti-MI)?
> 
> This is actually the reason, not the adamantly anti-MI part, just that MI is evil and that is well acknowledged almost everywhere. You will find good argumentation against it if you look, too.

Looking at superdan's message, gee whiz, that didn't take long to find the implementational reasons against it.

Reading about next-gen compilers like LLVM it makes me wonder with all that run-time type inferencing gizmo gadgetry available at virtually no cost, will this make MI (for those who want it) more feasible to implement?  Hmm, a curious possibility to consider.  LLVM is supposed to be wicked fast, too.  My Apple friend tells me that most of OS X's GL stack is built with LLVM for speed.  There might be something to it.

>> I don't know.  I know
>> I can add a lot with mixins, but I'd just like to know what the state of
>> the feature is.
>>
>> The reason is I was trying to explain how cool D is to some other friends of mine, and they asked about Multiple Inheritance (of classes) and they were sort of put off by it's lack of it.  Then again, he was an Objective-C programmer...  ;-)
> 
> In the languages where MI is possible, it usually also is possible to not shoot your own foot with some care, in which case it can appear as a powerful feature. But almost everywhere it just is a very bad idea, and you will find it is banned in many projects for languages allowing it (like C++).

Look long enough and you can find anything.  ;-)

I see your point though.

>> So please don't take offense, since none is meant, I just wanted to know what I could hope for in the future.
> 
> You should hope you can redesign your application to not need MI ;)

Yeah, it's trivial to work around it (I did come from Java!) but some bits and pieces seem like it would be better if they could inherit behavior and data, not just a contract.  It could be done through a mixin, but that defeats the polymorphism I want present in the design. And a Mixin and an interface just seems clunky.  What if I do the mixin but forget the interface, or vice-versa?  Yuk!  Though it would give me the option of re-implementing it differently if necessary...  a curious silver lining.



« First   ‹ Prev
1 2 3 4 5 6 7