Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

Btw,.. On 20.09.2016 18:18, Nevin Brackett-Rozinsky via swift-evolution wrote: I think there is a deeper issue that may be worth exploring here. Notably, when one class presents a member function, its subclasses ought to use “override” when they reimplement that method themselves, regardless

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

On 21.09.2016 9:30, Goffredo Marocchi via swift-evolution wrote: If the reference to the instance of the class is cast to the protocol type, I want other object to be aware of my API contract not the specific class instance, then the protocol default method gets called and that is several shades

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

Sent from my iPhone > On 21 Sep 2016, at 01:41, Zhao Xin wrote: > > > I am not sure why protocol extension need to differ so much and present > > dispatch rules that are potentially very confusing. > > I think that both the Java and Swift designers want to get the benefits

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

> I am not sure why protocol extension need to differ so much and present dispatch rules that are potentially very confusing. I think that both the Java and Swift designers want to get the benefits of multiple inherences, in the meaning time, they don't want to support multiple objects inherence.

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

I understand your point on "adding additional `override` to re-implementation of default method in protocol extension". However, I don't stand for it. If you use `override`, that means `B` could use `super.bar()` to get the original `bar()` implementation. Then if `class A` implement `bar()`

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

This would make for hilarious debugging session if you have the misfortune of using a third party binary framework that gets updated and provide default implementations for some methods in the protocol extensions. When Java 8 also decided to blur the lines between classes (implementations) and

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

I think there is a deeper issue that may be worth exploring here. Notably, when one class presents a member function, its subclasses ought to use “override” when they reimplement that method themselves, regardless of where the superclass’s version comes from. In the original post, the class “A”

Re: [swift-evolution] [swift-users] [swift-user]Unexpected behavior of protocol extension.

I can’t tell you the reason, but to me it feels like it’s doing the following thing: + - - (Type: B) - - + | | | func bar()+ - + (Type: A) - - +< - - - - - - - - - - - - - - - - - - - - + | | |