-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 2/17/2016 3:25 PM, Kevin Gessner wrote: > I've noticed s pattern in Etsy's code and elsewhere, where a trait > provides a common implementation of an interface. Classes that use > the trait are required to also explicitly declare the interface to > benefit. I propose that traits be permitted to declare and > implement interfaces. Classes that use such a trait would then > implement the interface, as though it were declared on the class, > without declaring the interface explicitly.
I agree with the others having a class implementing the interface automatically just because a trait implements it is not a good idea. The class should always decide on its own if it wants to implement an interface or not. Note that the situation with true inheritance (extends) is very different compared to the usage of a trait. When one extends a class it automatically agrees to the "is a" contract. In other words, it MUST implement all interfaces that any of the parents implements, otherwise it cannot fulfill the "is a" contract. Another thing that is important to note is that a class might want to use a particular trait but does not want to implement the interface in the first place. That being said, the actual thing one wants is that the IDE helps us to not overlook a method that we might forgot about while implementing that default trait for an interface. This is something where PHPDoc shines and should be used for. Actually I proposed this already for the upcoming PSR-5 that covers PHPDoc. However, that feature might be out of scope for the PSR. TL;DR Create feature requests for PHPDoc software (IDEs etc.) to support "@implements InterfaceName" (and maybe "@extends ClassName") in order to fulfill this use case and do not change the language. - -- Richard "Fleshgrinder" Fussenegger -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWxLkuAAoJEOKkKcqFPVVrJe4P/1Qz43ey6g7aEQUegOyfuoIQ GokTsUS42pedbGr3mYdf2/qatFp+/CyMv4FovLX4+m2wRn10AFmeYENi4RcFItb+ ILiiTynMPrQqV3IGgujHYwNDA/J4Qo3mn8FnNcLWl6nz3bFaxPTu2ygEgPYWz9Yu Y9qBcPqdQn1o/ipUf9D+thFzDKtCqCAEoPmBcCQWwCIK3yiUfqbkOzNBqynlE/qK 9lhCrF3+5XSrTkxl+gwzm9YUEA/EO7BUO6i8bXex9ZPDBSfRQet29DYUR9pGu8/p VMyHd9w1H60QCequreW4kZwixO010jKAO9EUwXMU/+yYV5C2Iy/5eRcKVERgLT75 BtKC0eNRW6kw58ZnRRYiVLfqlCZDQYU2kQ0S7R4Nym04agOZ2tdneKFgEYn3uo/k qNzaTLLYRbPNnfyYcZ4DRtsI82OIHrw2x8U9KrOU48fnvtLeW3+nShwXFK1oLU40 hsB+jU28OvsSohBngwAQn2z7nIJVqLiyVCnWj48omtzBJ7GesfIUt2Cu1cG9yK+/ EeCVIXhI9m1W5Wf2k8oEaB8Amy5rZwW6b1PA+JHJ+aYQjvG3CY6ipSka/RhRqAgf ABTLX8k1a7Hdd8kXheC1vIhhjLgIWijW59Bzg/oxN4RiRe2c90s4e857VN+fEBfK 6xVA5XfwMQ2N4tn+P2Zq =7rF9 -----END PGP SIGNATURE----- -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
