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

[Guy Murphy]

>>Makes no differency. Any mixin classes would still subclass
>>System.Object or one of its subclasses at the top of a diamond
>>inheritance pattern, meaning that the instantiation of any class that
>>uses mixins has multiple routes back up the tree to the "root"
>>constructor.

No not necessarily. If it has CLR support, then as a construct (note, not a class construct) then there's absolutely no reason why it has to inherit from root, or be instantiattable.

One wouldn't reasonably apply your agument to the Interface construct, so there's no reason why a mix-in  can't work in a similar fashion. And working thus, if mixins can only inherit from interfaces and other mixins there's no danger of a mixin presenting a full type or introducing a conflict.

>>Inheritance hierarchies should be strictly directed and acyclical. This
>>is why multiple inheritance is disallowed.

Firstly, a mix-in doesn't impact your agument here, as mix-ins can't be instantiated, they are simply for code reuse of interface implementations (or parts thereof).

Secondly, in your opinion class hierarchies should be strictly directed and acyclical... this is not a rule of law, but a matter of taste and prefered coding practice.

I personaly think multiple inheritence poorly serves when used gratuitously, but I'm a mature developer and I'll darn well make up my own mind as to how I model. I'll not be patronised by those who would corral me like an errant kid by a parent who knows best. Especially by those who'll simply post purist theory without answering real situational questions posed... still waiting for examples as to exactly why mixins pose such a danger.

Thirdly, OO is one model of development, not the only, and definately not always the most suitable for a given task. In the real world OO principles are used to a greater or lesser degree, alongside functional, and procedural principles, depending on the project (the project I've most recently finished, and am currently testing is an inference engine that has precious little to do with OO).

CLR *claims* (and I tend to lend weight to it's claim) to promote as much language agnosis as possible... C# may well be agressively OO, but that doesn't mean that Python.NET or Ruby.NET must be, and it certainly doesn't mean that Haskell.NET, or (more to my recent interest) Mercury should forsake their own paradigms for "Object Orientation According to Dummies".

This isn't a side issue for .NET (and therefore Mono), but is in fact a core issue. The strongest critisisms against the .NET strategy have been that it isn't language agnostic, and indeed is a charade of language skinning (which clearly isn't the case if one looks at ho Haskell has worked the issue)... but to turn around and say there is the one annointed way of OO, and all languages shall adhere is a good way to reduce .NET to the same scope as Java... a rather limited scope I might add, as there are many things OO is really rather poor at.

**Some langauges that are implimented in .NET wont even be OO languages** And some will have a very different take on what OO is, some not even using the same terminology.

Lastly...

>>Mixins are not interfaces, I know that. What I am saying is, interfaces
>>are what mixins should be.

Which is to totally miss the purpose of mix-ins.

The rest of this discussion can be continued off list if you so wish, as it's starting to get tangental to the core interest of the list, and after reading your original posts I think could have been nipped in the bud by you simply saying you hadn't understood what mixins where.

If you wish to continue the dialogue off-list you can start by letting me know if you're a CS student, or actualy work as a developer.

Cheers,
	Guy.