On Fri, Mar 4, 2016 at 2:06 AM, Rowan Collins <rowan.coll...@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
