| |||||||||||||
PHP 5.4.0 releasedPHP 5.4.0 releasedPosted Mar 2, 2012 12:21 UTC (Fri) by angdraug (subscriber, #7487)In reply to: PHP 5.4.0 released by oseemann Parent article: PHP 5.4.0 released
No, mixins were invented specifically to avoid multiple inheritance when reusing code from multiple classes. They only exist in languages with single inheritance. According to that Wikipedia article I linked to earlier, PHP traits are mixins, which is why I'm curious why they had to invent their own name for a well-known concept.
(Log in to post comments)
PHP 5.4.0 released Posted Mar 2, 2012 15:25 UTC (Fri) by pboddie (subscriber, #50784) [Link]
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.
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).
PHP 5.4.0 released Posted Mar 2, 2012 22:55 UTC (Fri) by robert_s (subscriber, #42402) [Link]
"No, mixins were invented specifically to avoid multiple inheritance when reusing code from multiple classes. They only exist in languages with single inheritance."
The term (& technique) is very heavily used in the Python world to perform exactly what oseemann is describing.
PHP 5.4.0 released Posted Mar 3, 2012 0:49 UTC (Sat) by elanthis (guest, #6227) [Link]
It's not true to say that the only exist in languages with single inheritance.
There's plenty of reason to have them even with multiple inheritance. Mixins can implement part of one or more interfaces, can include new members and methods, and -- this is most important -- can freely call into the class using the mixin.
In C++, which has no mixins, it is common to use a template to implement a mixin. Unfortunately it is not a "real" mixin due to various limitations the inheritance-based approach imposes. You can work around most of those with a lot of overly verbose syntax using CRTP, but it'd be nice if you didn't have to.
|
|||||||||||||