Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91382
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.218.54 as permitted sender)
MIME-Version: 1.0
References: <CAF8MkRhYJZApgQbr16DmDdFxET9ORkah9jxabL7nbHFKYh0N1A@mail.gmail.com>
 <CAF8MkRgyEk4-JjxuxqVo7pO12jXRehpDGtYzLshD6PuLUdJCkA@mail.gmail.com>
 <CAF8MkRjpSk_TdP_CekNy4FG0g15oxeECO=_ocg4a_8QTa6e8Uw@mail.gmail.com>
 <CAF8MkRghhr=hc_PbNVNPAUhVZFa1fCZcSzc6LBis_Lgn0W4z8A@mail.gmail.com>
 <CAAn=CzWBqP72pD=PuazeiZniCnr4mB+7noDDgbvmRx64-t5LGg@mail.gmail.com>
 <CABHuAWyJjKLYKn=EtX+FUt0uJ7gWXwg0GUW-55UJzfnNtrjKCg@mail.gmail.com> <CAF8MkRjoC7AeUcEB50714Q0kCpCjVSqFS_P46x4rJ_xst3E00A@mail.gmail.com>
In-Reply-To: <CAF8MkRjoC7AeUcEB50714Q0kCpCjVSqFS_P46x4rJ_xst3E00A@mail.gmail.com>
Date: Wed, 24 Feb 2016 22:04:20 +0000
Message-ID: <CAPKYkKywd6=byE1A7poxJvqBKOh4Q_VZBzT5CNg5HWnLhXHkDQ@mail.gmail.com>
To: Kevin Gessner <kgessner@etsy.com>, Chris Riley <t.carnage@gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a113db77808680c052c8b4009
Subject: Re: [PHP-DEV] Re: [RFC] Traits with interfaces
From: chasepeeler@gmail.com (Chase Peeler)

--001a113db77808680c052c8b4009
Content-Type: text/plain; charset=UTF-8

On Wed, Feb 24, 2016 at 4:46 PM Kevin Gessner <kgessner@etsy.com> wrote:

> On Tue, Feb 23, 2016 at 4:48 AM, Chris Riley <t.carnage@gmail.com> wrote:
>
> > This isn't such a great idea as it will cause some of traits
> functionality
> > to be broken: I can currently use a trait and alias its methods and
> change
> > their visibility. If a trait implements an interface which is copied onto
> > my class I can no longer do this as the compiler will throw a fatal error
> > for the class not correctly implementing the interface that got copied
> from
> > the trait.
> >
>
> This is only true under Proposal 2 of the RFC, and this is listed as an
> open issue: https://wiki.php.net/rfc/traits-with-interfaces#proposal_2
>
> Proposal 1, where the engine enforces interface declarations on traits,
> doesn't affect how traits are inserted and still allows aliasing.
>
>
> > If you decide to continue pursuing this RFC, I'd like to see some thought
> > given to the above; perhaps it could be as simple as not copying the
> > interface if aliases/visibility changes are made in the use or perhaps
> > something more complex which allows specifying which interfaces should be
> > copied into the class from the trait.
> >
>
> I agree that there are several reasonable solutions here, but I'm not sure
> which is the best.  It does feel too aggressive to have it be a fatal error
> if aliasing undoes the interface implementation.  At the same time,
> introducing new syntax to enable aliasing to work with interface
> propagation defeats the purpose, which is to make it easier and simpler to
> implement an interface via a trait.
>
> I'd be interested to hear if you have any ideas about how this should
> look.  I'm mostly unfamiliar with aliasing traits in practice, so I'd be
> curious to see how this RFC would affect your code.
>
> Since the class doesn't know you are using the trait to implement the
interface, if you alias the trait method, then the class no longer
implements the interface unless it defines the method that is now missing
itself.

Remember, the contents of the trait are just getting copy/pasted into the
class. If you alias a method, then the method gets pasted in using the
alias, not the original name.

That being said, it should be rare that you would alias a method and then
not implement the method yourself - as the need to redefine/expand on its
functionality is the reason you usually alias a trait method.



> Cheers
> -- Kevin
>
-- 
-- Chase
chasepeeler@gmail.com

--001a113db77808680c052c8b4009--