| |||||||||||||
PHP 5.4.0 releasedPHP 5.4.0 releasedPosted Mar 2, 2012 15:25 UTC (Fri) by pboddie (subscriber, #50784)In reply to: PHP 5.4.0 released by angdraug Parent article: PHP 5.4.0 released
At least as far as I have seen, mixins/mix-ins in their most general sense are actually intended to avoid multiple inheritance of common functionality or concerns, and they actually rely on a viable multiple inheritance mechanism. So, you would make a class inherit from several mix-ins associated with orthogonal or non-overlapping functionality, concerns or concepts, potentially incorporating code from each of them (hence the need for functioning multiple inheritance), safe in the knowledge that you won't run into weird invocation order or initialisation problems which arise when it turns out that various classes you've inherited have a common ancestor.
(Log in to post comments)
PHP 5.4.0 released Posted Mar 2, 2012 15:46 UTC (Fri) by rfunk (subscriber, #4054) [Link]
I think it's a matter of your definition of mixin and ultiple-inheritance. Support for mixins can be a way for an otherwise single-inheritance language to support a form of multiple-inheritance. Does that make it a multiple-inheritance language?
The specific example I'm familiar with is Ruby, which supports mixins ("modules"), but is otherwise an explicitly single-inheritance language. It uses a form of implicit ordered search path/chain to determine which method runs if there are multiple candidates.
PHP 5.4.0 released Posted Mar 3, 2012 0:24 UTC (Sat) by pboddie (subscriber, #50784) [Link]
Well, if we distinguish between inheritance (meaning the adoption of code, its interfaces and potentially attributes or members from a parent abstraction) and conformance (meaning the adoption of an interface from an abstraction), it seems to me that the latter isn't enough to give you mix-ins. So in Java you traditionally couldn't mix functionality into a class from more than one superclass, but you could declare conformance to a number of interfaces, but that would still leave you with filling in the missing functionality in a concise fashion. Mixing typically implies the involvement of more than one thing, and single inheritance doesn't really provide much scope for that. I suppose that these traits allow the inclusion of code originating from outside any defined conformance hierarchy, which reminds me somewhat of aspect-oriented programming, if I recall the nature of that correctly.
I've used mix-ins in Python where multiple inheritance is possible (according to the above definitions), but where you want to avoid method resolution uncertainty or general untidiness, although I'd argue that architectures based on mix-ins can be quite stifling and that other mechanisms exist in Python that are preferable (mostly due to Python's dynamic typing and objects-as-callables support).
|
|||||||||||||