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