[Mono-list] Re: Is Objective-C support possible?

Guy Murphy guy.murphy@calaba.com
Mon, 18 Feb 2002 12:15:31 -0000


>>Whether you like it or not, ther is a "One True Way" here- the CLR way.
>>It's not religion, it's the runtime you're working with. It has already
>>been established that Multiple Inheritance was not allowed in the CLR
>>because of the problems of diamond inheritance and over-complex
>>instantiation rules, and also that mixin functionality can be achieved
>>using the decorator pattern.

For the last time... mix-ins do not have a constructor and therefore do not impact instantiation.

The issue of which method is used from a mix-in under multiple mix-in inhreitence is no more complex than it is for multiple interface inheritence.

It has been obvious from your first comments on mix-ins (confusing them with interfaces) that you're not really sure what they are.

>>The Gang of Four book goes into elaborate detail for all of this. As far
>>as most OO programmers are concerned, it *is* the recieved wisdom on OO
>>programming and I will certainly continue to treat it as such.

Well I'm glad that most programmers have elected you as their spokesperson, but given the number of languages with OO support that live quite happily with mix-ins, excuse me if I don't take the wisdom you recieve as that for most programmers... I'm still waiting for you to tell me specifically what dangers mix-ins introduce, which should be easy given how sure you are that they're deadly, and a really really Bad Thing(TM) in OO.

The reason why I first brought up mixins under CLR, is that because if the CLR allows multiple interfaces, there is no reason why it shouldn't allow mix-ins.

I welcome comments from others as to hidden dangers that I might not be considering who actually know what a mix-in is.

It should also be remembered that much (not all) the target market for .NET is RAD and Web Development, where the simple fact is that one must balance good coding practice with rapid development... mix-ins aid rapid development, and probably do more to propagate safety in facilitating reuse, than any notional dangers because they notionaly "break encapsulation" (although I'm waiting to hear what innards they expose).