View mode: basic / threaded / horizontal-split · Log in · Help
August 12, 2008
Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Re: Multiple Inheritance of Classes
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
Top | Discussion index | About this forum | D home