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

Reply via email to