Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:91513
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain daveyshafik.com from 74.125.82.45 cause and error)
MIME-Version: 1.0
Sender: me@daveyshafik.com
In-Reply-To: <56D95E18.9020007@gmail.com>
References: <CAF8MkRhYJZApgQbr16DmDdFxET9ORkah9jxabL7nbHFKYh0N1A@mail.gmail.com>
	<94.96.08749.188B8D65@pb1.pair.com>
	<CANaX5nfHALhKJcf2B46sz0hc5gDu+dY7J_kD17SM=MXH4hLvqg@mail.gmail.com>
	<56D95E18.9020007@gmail.com>
Date: Sat, 5 Mar 2016 15:15:58 -0800
Message-ID: <CANaX5ne6s+q8tBRgt0WetC5z8R7C5Rc5-cqXB7frXQiSZ4WO9A@mail.gmail.com>
To: Rowan Collins <rowan.collins@gmail.com>
Cc: "internals@lists.php.net" <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1146762c123543052d556a19
Subject: Re: [PHP-DEV] Re: [RFC] Traits with interfaces
From: davey@php.net (Davey Shafik)

--001a1146762c123543052d556a19
Content-Type: text/plain; charset=UTF-8

On Fri, Mar 4, 2016 at 2:06 AM, Rowan Collins <rowan.collins@gmail.com>
wrote:

> Davey Shafik wrote on 04/03/2016 07:17:
>
>> 1. If you simply alias (use foo { bar as bat; }) then you end up with an
>> *additional*  method with the new name, the trait method as defined is
>> still
>> brought in, and_will_  override inherited methods of the same name.
>>
>
> Here's a clearer example of this: https://3v4l.org/RKHPt
>
> Unfortunately, you can't even use "insteadof" to directly bring the parent
> method back in [https://3v4l.org/qOS5T], but you can stub it out with a
> direct call to parent:: [https://3v4l.org/s9i4N].
>
> 3. Doing this (visibility + name)_only_  gives you the new method, which is
>> _different_  behavior to #1
>>
>
> I can't reproduce this: if I say "bar as private bat", the trait's bar
> still shows up, and is public, just as in the previous example:
> https://3v4l.org/1jH6o
>
> Your examples are rather confusing because they are effectively applying
> the same trait twice, at different levels of the hierarchy; I'm not sure
> this is a particularly likely scenario, or relevant to how interfaces
> should behave.
>
> Regards,


Rowan,

You are mid-reading, none of the classes in my examples extend the others,
they are all just using the same trait in different ways.

- Class a: use the trait with no aliases. Result: as expected
- Class b: use the trait with a simple alias, no visibility change. Result:
both methods
- Class c: use the trait with and alias both name, and change visibility.
Result: ONLY the aliased method
- Class d: use the trait and "alias" to the same name, ONLY changing
visibility. Result: causes a Fatal error, clashing with itself o.O

For the one you can't re-produce, it's class 'c', which is stand-alone
here: https://3v4l.org/K9o6Y

- Davey

--001a1146762c123543052d556a19--