Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:91400 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 67451 invoked from network); 25 Feb 2016 12:28:58 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 25 Feb 2016 12:28:58 -0000 Authentication-Results: pb1.pair.com header.from=t.carnage@gmail.com; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=t.carnage@gmail.com; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.42 as permitted sender) X-PHP-List-Original-Sender: t.carnage@gmail.com X-Host-Fingerprint: 74.125.82.42 mail-wm0-f42.google.com Received: from [74.125.82.42] ([74.125.82.42:36350] helo=mail-wm0-f42.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 7C/E5-29886-883FEC65 for ; Thu, 25 Feb 2016 07:28:57 -0500 Received: by mail-wm0-f42.google.com with SMTP id g62so26265768wme.1 for ; Thu, 25 Feb 2016 04:28:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc :content-type; bh=PNLS+hsCLTRZ24tMKeZIAWX1HcaTucF7wGWVsO945KE=; b=tqeQbulirmmvDiZ/iLqTtN7nciNtzv+kFFGmaxOT+nOj4D6Yy7sjipHin9QCiPa9qh H151L/g6d13HpIRt3iXNGlXJSPRnjp3/n99Tji2szvED4ge4yHHuelGkBg/sHnZkAIds aaNQh9QhjmNgCn1kX4JgNZ6bpMgICGgqhl3rRCi20vq31emmITkpkqmUJGaAYnsAXFxd avohsTFCY0mcjtRf9mpNzEH3++ib1atO5X/s4FqmDAJo+PmMovaRCJx1pQx6hivLA1Wc Dq7EEl5rOxohzJ+C/56F8rfigjuJLFMlaZCExDeXsAOQIeKqrVxsn1iohuD1sxcco/DE exnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc:content-type; bh=PNLS+hsCLTRZ24tMKeZIAWX1HcaTucF7wGWVsO945KE=; b=RhkQIYs50AuKnHgW3b8cBFZNThggcXRZfhbeOvROi49zg5q+iNyPbqmA+BcifQ/sac OeLQvN00q5exHz0HPOx61GHJjPcW/joqBEwMrUZmIQKoxA/xkyK/F5P+LOS6SmRhfcGl W1jeHt1Bjyvs2uZ+JYaJW1Y4AlVwKNTzhx4urL//SrsNgB7KGoDZ9kbFHH/pxDzolyYr NGU01tlDFjtiJFgyzLJf+FPtRv+O2XjJG9itTjGPkWGe9mcj8zSXBeckt5HEpJiJ5VHs G3WPX7RYBdfnwT1hAqvuV42h+h0lLhBH7F+gMjh9kraMwUQStGjQWUKBAfIOxLstfrdZ DB+A== X-Gm-Message-State: AG10YORNkoOrSiPi2tmigBgwxu430Ow1RJonKgmgpNizx1ii1lLdGnqzbEJzdKDA4UqBfpki9Huq1LS8TwRtXg== MIME-Version: 1.0 X-Received: by 10.194.3.110 with SMTP id b14mr44983433wjb.116.1456403334339; Thu, 25 Feb 2016 04:28:54 -0800 (PST) Received: by 10.194.122.201 with HTTP; Thu, 25 Feb 2016 04:28:54 -0800 (PST) In-Reply-To: References: Date: Thu, 25 Feb 2016 12:28:54 +0000 Message-ID: Cc: PHP Internals Content-Type: multipart/alternative; boundary=047d7b33dc5064a3a4052c97531c Subject: Re: [PHP-DEV] Re: [RFC] Traits with interfaces From: t.carnage@gmail.com (Chris Riley) --047d7b33dc5064a3a4052c97531c Content-Type: text/plain; charset=UTF-8 On 24 February 2016 at 22:04, Chase Peeler wrote: > > > On Wed, Feb 24, 2016 at 4:46 PM Kevin Gessner wrote: > >> On Tue, Feb 23, 2016 at 4:48 AM, Chris Riley 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 > Aliasing isn't something I use often; however changing visibility is - such that the methods in the trait become an implementation detail for the class in question and don't pollute it's public API. That would break if an interface was copied onto my class. --047d7b33dc5064a3a4052c97531c--