Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91259
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain etsy.com designates 209.85.192.41 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <56C4B92E.9020306@fleshgrinder.com>
References: <CAF8MkRhYJZApgQbr16DmDdFxET9ORkah9jxabL7nbHFKYh0N1A@mail.gmail.com>
	<56C4B92E.9020306@fleshgrinder.com>
Date: Wed, 17 Feb 2016 15:01:31 -0500
Message-ID: <CAF8MkRi3s7mUKW26L1Gt=ewHvQ79zzVF8WBzNaHcroO7o0PLhQ@mail.gmail.com>
To: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113a74f65d11c6052bfcb79a
Subject: Re: [PHP-DEV] [RFC] Traits with interfaces
From: kgessner@etsy.com (Kevin Gessner)

--001a113a74f65d11c6052bfcb79a
Content-Type: text/plain; charset=UTF-8

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
>
>

--001a113a74f65d11c6052bfcb79a--