Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91271
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain etsy.com designates 209.85.192.44 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAFMT4NpZeWcdCALgJN7khmPqAC436Hfw4gTDqXvT8tnqQQcdHA@mail.gmail.com>
References: <CAF8MkRhYJZApgQbr16DmDdFxET9ORkah9jxabL7nbHFKYh0N1A@mail.gmail.com>
	<CAFMT4No27q87iiNHPYCb=MnX7HK5gFh5PZyB4M2Xpt=HWXw53Q@mail.gmail.com>
	<CAF8MkRj++uvzrxD+SJrjd-1_yeOg5QhOFVzmnryKF1+bSkzY9w@mail.gmail.com>
	<CAFMT4NpZeWcdCALgJN7khmPqAC436Hfw4gTDqXvT8tnqQQcdHA@mail.gmail.com>
Date: Thu, 18 Feb 2016 12:48:37 -0500
Message-ID: <CAF8MkRjb=yeG3CCLRUX6Uw8S+rjD6LT+mUSQthO9yRyh2=cdTw@mail.gmail.com>
To: Levi Morrison <levim@php.net>
Cc: internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a11355138ea2950052c0ef99d
Subject: Re: [PHP-DEV] [RFC] Traits with interfaces
From: kgessner@etsy.com (Kevin Gessner)

--001a11355138ea2950052c0ef99d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, Feb 17, 2016 at 6:13 PM, Levi Morrison <levim@php.net> wrote:

> On Wed, Feb 17, 2016 at 12:48 PM, Kevin Gessner <kgessner@etsy.com> wrote=
:
> > I don't think there is enough benefit from allowing traits to declare
> > interfaces, but not propagating the interface out to classes that inser=
t
> the
> > trait.  It does provide an extra bit of enforcement on the trait's
> methods,
> > 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 woul=
d
> > also declare Iterator, it's needless repetition to require that both th=
e
> > 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.
>

Thanks, Levi, that makes sense.  In my existing RFC, the case of changing
the visibility of an included method would cause a fatal error (as the
including class would no longer fulfill the interface), but that's not the
only reasonable behavior.  I can make this an open question in the RFC.

It sounds like this summarizes most people's feelings at this point: adding
interfaces to trait declarations is a reasonable change, but propagating
the interfaces out to classes is contentious.

I'm leaning at this point toward splitting the RFC (
https://wiki.php.net/rfc/traits-with-interfaces) into two proposals:

1. Allow a trait to declare one or more interfaces via the `implements`
keyword on the trait definition.  The engine will enforce that the trait's
methods fulfill the interface.
2. A class, by including a trait that declares interfaces, will implicitly
be declared to implement those interfaces.

The vote on 2 would be moot if the vote on 1 does not pass.  The
combination of these is the existing RFC as a single proposal; I'd keep it
as a single RFC with two proposals and two voting sections, voted
separately but concurrently.  It looks from history like multiple voted
proposals on one RFC is OK, but please let me know if I'm violating
protocol in some way.

Would folks be amenable to that change to the RFC?

Cheers
-- Kevin

--001a11355138ea2950052c0ef99d--