Multiple Inheritance of Classes

Chris R. Miller lordSaurontheGreat at gmail.com
Tue Aug 12 17:24:23 PDT 2008


superdan wrote:
> Chris R. Miller Wrote:
> 
>> 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.
> 
> the sinner tells the truth dood. it's not the implementation reasons. it's the reasons, period. there's no others. with one exception (smalltalk) all languages without fixed field layout do use mi. why? because aside from field layout there is no reason not to, and they already paid the price. this "it's evil" bullshit comes from c++ people tryin' it in wrong ways. just like java 1 zealots yelled all over that generics are crap. then java 5 added (assfucked) generics. guess what. javaots changed their stance. sorry about the argument by comparison fallacy :)

That's humorous coming from you, seeing as how you tauted nothing but 
implementation reasons.

I know a lot of Java "zealots," and they were never anti-template.  The 
zealots in your neck of the woods must be more bipolar than mine.

>> 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'll make another analogy. with all that research n shit, isn't perpetual motion closer to reality now? hell no. the fact that llvm is fast or smart has nothing to do with basic graph topology. the problem definition makes a solution impossible. this will be broken when someone invents some associative memory shit or some fundamental breakthrough. or when the cost of malloc and indirection becomes small enough to be affordable (solution through tradeoff inversion).

Perpetual motion is slightly different than a new and experimental 
approach to a compiler.

>>>> 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.
> 
> i don't. he has none. he keeps on saying it's a "very bad idea". he could sing it for all i care. how does that make it more pointful.

You continue to amuse me.  First I say I see his point.  You say you 
don't.  You say he has no point.  Therefore you're absolutely certain 
that even though someone else sees his concept that it is either false 
or not there, or both.

>>>> 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.
> 
> the silver lining is in introspection. with it you can define classes that define forwarding functions to other classes. that is almost mi, good enough for many uses.

I don't see how that would restore polymorphism.  Short code example, 
perhaps?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 258 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20080812/f4c374c6/attachment.pgp>


More information about the Digitalmars-d mailing list