Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91261
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.220.48 as permitted sender)
MIME-Version: 1.0
Sender: morrison.levi@gmail.com
In-Reply-To: <CAF8MkRj++uvzrxD+SJrjd-1_yeOg5QhOFVzmnryKF1+bSkzY9w@mail.gmail.com>
References: <CAF8MkRhYJZApgQbr16DmDdFxET9ORkah9jxabL7nbHFKYh0N1A@mail.gmail.com>
	<CAFMT4No27q87iiNHPYCb=MnX7HK5gFh5PZyB4M2Xpt=HWXw53Q@mail.gmail.com>
	<CAF8MkRj++uvzrxD+SJrjd-1_yeOg5QhOFVzmnryKF1+bSkzY9w@mail.gmail.com>
Date: Wed, 17 Feb 2016 16:13:24 -0700
Message-ID: <CAFMT4NpZeWcdCALgJN7khmPqAC436Hfw4gTDqXvT8tnqQQcdHA@mail.gmail.com>
To: Kevin Gessner <kgessner@etsy.com>
Cc: internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] [RFC] Traits with interfaces
From: levim@php.net (Levi Morrison)

On Wed, Feb 17, 2016 at 12:48 PM, Kevin Gessner <kgessner@etsy.com> wrote:
> On Wed, Feb 17, 2016 at 10:26 AM, Levi Morrison <levim@php.net> wrote:
>>
>> I want to add my personal experience with traits: every time I create
>> a trait it is to implement an interface. Here is a publicly available
>> [example with
>> OuterIterator](https://github.com/morrisonlevi/Ardent/blob/master/src/Co=
llection/OuterIteratorTrait.php):
>>
>> [snip]
>>
>> I can see how it would be nice to allow the trait to officially
>> declare that it implements some interface (in this case Iterator or
>> OuterIterator) which would require that the trait has fully
>> implemented the required methods (or declared them as abstract). This
>> would be a small improvement but helpful.
>>
>> I am less certain about the classes which `use` it automatically
>> inheriting the interfaces. To clarify: I am neither in favor or
>> against that part. Or at least at this stage, anyway.
>
>
> I don't think there is enough benefit from allowing traits to declare
> interfaces, but not propagating the interface out to classes that insert =
the
> trait.  It does provide an extra bit of enforcement on the trait's method=
s,
> but the real value is in making that contract a part of the classes.

I do agree that there is only a little benefit but I disagree that it
is "not enough". It's a quality of life change to an existing feature
that has no impact outside of that feature =E2=80=93 sounds perfect to me.

> In what situation would a class that inserts OuterIterator not want to
> declare the Iterator class?  If every class that inserts the trait would
> also declare Iterator, it's needless repetition to require that both the
> class and the interface.

Funny you should ask, because OuterIteratorTrait implementing
OuterIterator is actually a case where not all using classes will want
to be OuterIterators formally (just get the horizontal code reuse).
This is because I don't want to "leak" the inner iterator because it
is suppose to be abstracted. In these cases I use the syntax for using
a trait method under a different visibility.