Re: [RFC] Traits with interfaces
| From: | Kevin Gessner | Date: | Wed, 17 Feb 2016 20:01:31 +0000 |
| Subject: | Re: [RFC] Traits with interfaces | ||
| References: | 1 2 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-91259@lists.php.net to get a copy of this message | ||
On Wed, Feb 17, 2016 at 1:17 PM, Fleshgrinder <php@fleshgrinder.com> wrote:
> 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.
>
I'm not clear on the motivation for this principle. Is there anything I
could read up about explicit vs implicit in PHP design?
>
> 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.
>
What cases are you thinking of here? I'm trying to come up with an example
where a class that wouldn't want an interface provided by a trait it uses.
>
> 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.
>
I don't use a PHPDoc-aware IDE (I'm old fashioned), so I'd want any change
to be part of the language itself, where enforcement is guaranteed.
>
> - --
> 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
>
>