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 of
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
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 of
> multiple inh
> 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.
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()`
some
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
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” e
Thank you to Игорь Никитин and Adrian Zubarev. Now I can convince myself
for this behavior.
As Adrian's example shows, there is no `bar()` implemented in `class A`, so
there is no `override func bar()` in class B`. My thought that `self.bar()`
would do the same as `(self as! B).bar()`, is called
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) - - +< - - - - - - - -
- - - - - - - - - - - - +
| | |