| |||||||||||||
PHP 5.4.0 releasedPHP 5.4.0 releasedPosted Mar 2, 2012 10:35 UTC (Fri) by angdraug (subscriber, #7487)In reply to: PHP 5.4.0 released by apoelstra Parent article: PHP 5.4.0 released
Thanks, that's very helpful. From the looks of it, PHP traits are implement the concept of Mixin, did they have a reason to make up their own name for it?
(Log in to post comments)
PHP 5.4.0 released Posted Mar 2, 2012 12:11 UTC (Fri) by oseemann (subscriber, #6687) [Link]
Maybe because Mixins are ideally used with multiple inheritance, where you inherit from the base class plus any number of mixins. PHP only does single inheritance, if I am not mistaken.
PHP 5.4.0 released Posted Mar 2, 2012 12:21 UTC (Fri) by angdraug (subscriber, #7487) [Link] 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.
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.
PHP 5.4.0 released Posted Mar 2, 2012 15:40 UTC (Fri) by rfunk (subscriber, #4054) [Link]
PHP has a strange habit of using slightly wrong nomenclature when they add "advanced" features, so I'd rather they just made up their own name than get it wrong.
(The particular example I'm thinking of is using "closures" to mean "lambdas" or "anonymous functions", while in fact actual closures are clumsy there.)
PHP 5.4.0 released Posted Mar 2, 2012 16:20 UTC (Fri) by artem (subscriber, #51262) [Link]
I just checked some of the languages that wikipedia article claims to support 'Mixin' concept:
Scala - uses 'trait' to denote classes that you can 'mix in' into other classes
Ruby - does not use the word 'mixin'
Groovy - uses @Mixin annotation for classes that have other classes 'mixed in'
Vala - does not use the word 'mixin', just allows to define methods in interfaces
So 'Mixin' is just a vague concept, and you have to be precise when defining a language. And it just sounds weird - trait is so much better IMHO.
PHP 5.4.0 released Posted Mar 2, 2012 19:03 UTC (Fri) by rfunk (subscriber, #4054) [Link]
Ruby doesn't use the word "mixin" itself, but the Ruby community does.
PHP 5.4.0 released Posted Mar 2, 2012 21:31 UTC (Fri) by artem (subscriber, #51262) [Link]
So, I see it as PHP agreeing with Scala and disagreeing with Ruby in their choice of the name. They did not invent their own name.
|
|||||||||||||