Well, I have a few opinions on this that I think are worth sharing: 1. If this change is made, we no longer would have mixins, but would have regular multiple-inheritance (With all the "issues" associated with it). Note that I said mixins and not traits. That's because since these were implemented with state (member properties), they are not traits as implemented, but regular mixins. (Yet another gripe, but that's slightly off topic).
2. Traits and mixins are supposed to be the symmetric counterpart to interfaces. An interface is a specification without implementation. A trait/mixin is supposed to be implementation without specification. And a class (including abstract) is implementation with specification. So if you allowed type hinting of traits/mixins, wouldn't that just make them nothing more than abstract classes (in that they can't be used directly, but both provide the same info)? There's a much bigger problem though. How would you solve the problem where a class uses a trait that implements an interface, but you don't pull one of the methods through (for example, you exclude it in the use clause)? At first this sounds simple, just enforce it on the class. But that means that the compiler couldn't enforce the interface at definition time of the trait. So then that means that by the trait implementing the interface is actually *forcing* any class that implements it to be compliant and ensure that it implements the interface. So at that point the trait stops being useful for horizontal reuse, but becomes nothing more than a class with the limitations that brings along. Traits/mixins were designed to avoid this problem. So why should we re-introduce it? Some of that is design choice, but I think we need to realize that there are a lot of people who have thought about these problems before in other areas of CS. What do other languages do? Can you name one mainstream language that implements traits/mixins as a first class citizen where they can implement an interface or can be type-hinted against? In fact, the original paper the RFC references (http://scg.unibe.ch/archive/papers/Duca06bTOPLASTraits.pdf) explicitly recommends separating the specification (interface) from the trait: A quote from that paper: > We solved these problems by creating traits for the different collection > properties and > combining them to build the required collection classes. To achieve maximum > flexibility, > we separated the properties specifying the implementation of a collection > from the > properties specifying the interface. This allowed us to freely combine > different interfaces (e.g., > “sorted-extensible interface” and “sorted-extensible-immutable interface”) > with any of the > suitable implementations (e.g., “linked-list implementation” and “array-based > implementation”). So in all, I feel it would be a significant mistake to allow traits (mixins) to implement interfaces or be type-hinted against. It goes against the principles that they were designed with and destroys some of their key benefits... Anthony On Sat, Oct 22, 2011 at 4:38 AM, Nathan Nobbe <quickshif...@gmail.com> wrote: > Hi folks, > > With a 5.4 release right around the corner I'd like a moment of your time to > reconsider this issue [1]. > > I've read through the original conversation [2] and would summarize the > points as follows: > > . several folks see value in the feature > . the feature would not be an impedance for people who did not wish to use > it > . there was only one objection which was largely subdued > > The common use case of pairing traits with interfaces is the case where the > feature adds value. > > Just curious why it died on the table if several folks saw value in it, > including Stephan who I gather is the primary architect of traits. > > The dispute regarding the feature was the merit of a 'compile time' check vs > placing the burden on the developer to ensure all methods in a trait are > provided by the class in which it is used. In an earlier conversation about > traits Stefan said this: > > "Yes, Traits are meant to be compile-time only, they are not used to > introduce typing relationships." > > Which makes me even more comfortable about the merit of another compile time > check. As I argued in the original thread, the feature is merely an > embellishment atop the already supported use of the 'abstract' keyword as it > pertains to traits. And what if nothing else are features like PPP, > abstract, interfaces etc than syntactic sugar? Plus it will save folks some > typing :) > > [1] > https://wiki.php.net/rfc/horizontalreuse#requiring_composing_class_to_implement_interface > [2] http://marc.info/?l=php-internals&m=129188077704898 > > thanks, > > -nathan > -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
