Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91269
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.214.182 as permitted sender)
MIME-Version: 1.0
References: <CAF8MkRhYJZApgQbr16DmDdFxET9ORkah9jxabL7nbHFKYh0N1A@mail.gmail.com>
 <CAF8MkRgyEk4-JjxuxqVo7pO12jXRehpDGtYzLshD6PuLUdJCkA@mail.gmail.com> <1455791700.2381299.524770354.2D139723@webmail.messagingengine.com>
In-Reply-To: <1455791700.2381299.524770354.2D139723@webmail.messagingengine.com>
Date: Thu, 18 Feb 2016 15:11:39 +0000
Message-ID: <CAPKYkKxY8U96xMauL_9CON9wdh6NK=CKeveLA+g_2baVAZzwiw@mail.gmail.com>
To: Larry Garfield <larry@garfieldtech.com>, internals@lists.php.net
Content-Type: multipart/alternative; boundary=001a113d550823704f052c0cc99c
Subject: Re: [PHP-DEV] Re: [RFC] Traits with interfaces
From: chasepeeler@gmail.com (Chase Peeler)

--001a113d550823704f052c0cc99c
Content-Type: text/plain; charset=UTF-8

On Thu, Feb 18, 2016 at 5:35 AM Larry Garfield <larry@garfieldtech.com>
wrote:

> On Wed, Feb 17, 2016, at 01:05 PM, Kevin Gessner wrote:
> > On Wed, Feb 17, 2016 at 9:25 AM, Kevin Gessner <kgessner@etsy.com>
> wrote:
> >
> > > Hello internals team!  I'd like to propose an RFC to allow traits to
> > > implement interfaces.
> > >
> >
> > I've created a proper RFC wiki page here with the draft:
> > https://wiki.php.net/rfc/traits-with-interfaces
> >
> > It includes more detail and several example code snippets.  Thanks all
> > for
> > your feedback so far.
>
> Thanks, Kevin.
>
> At the risk of a "me too" post, I would also be in favor of allowing
> traits to declare an interface but NOT in favor of a use-ing class
> implicitly implementing the interface as a result.  I'd rather the class
> still need to self-declare the interface; that it uses a trait to
> fulfill that contract is irrelevant to the outside world.
>
I agree, in theory, but I also think we introduce confusion. Every other OO
rule says you get "everything*" from what you are using (extending a
subclass gets you all the parent classes, implementing an interface that
extends an interface gets you the parent interface, using a trait that uses
a trait gets you both traits, etc). Perhaps we need a different keyword?

trait foo providesfor myInterface {
}

I'm not sold on that keyword, it's just the first thing that came to mind.

*I know you don't get private methods and properties in subclasses, but
that's something dictated by the class itself. The class says "you can't
have these if you extend me" instead of the engine saying "you aren't
implementing that when you use the trait because it's a trait"

At that point, the benefit becomes two-fold:
>
> 1) Communicate to users of the trait what the intent of the trait is: To
> provide the boilerplate for some interface, or portion thereof.  This
> could be covered by PHPDoc, potentially, and I've suggested the same for
> PSR-5 before.
>
> Agreed


> 2) Ask the engine to do a syntax check on the class to make sure I did
> not forget something or screwed up in some way.  That is, not fulfilling
> the interface on the trait would cause a parse error (or an error in my
> IDE), forcing me to fix my bug before I even try running it.  PHPDoc
> would NOT have this benefit.
>
> Thus I feel this addition does have value that a PHPDoc alternative
> would not.
>
> Good point. I was of the opinion "we can just use comments to declare
intent," but hadn't really thought of using the engine in this way. It
makes sense.




> --Larry Garfield
>
> --
> PHP Internals - PHP Runtime Development Mailing List
> To unsubscribe, visit: http://www.php.net/unsub.php
>
> --
-- Chase
chasepeeler@gmail.com

--001a113d550823704f052c0cc99c--