[swift-evolution] Static Dispatch Pitfalls

[Matthew Johnson]

Sent from my iPad

> On May 21, 2016, at 7:05 AM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Making them final is not a good idea. I see the default implementations in protocols as something that should replace the optional methods in @objc protocols. Example - a delegate protocol for table view (either UITableView or NSTableView): How would you represent it in pure non- at objc Swift? If it was a regular protocol, you'd need to implement all the methods.
> 
> With default implementations, the default implementation returns a default value and you don't need to implement this method from the protocol.

This thread isn't default implementations of protocol requirements.  Those are dynamically dispatched.  This thread is about *new* methods introduced in protocol extensions.  These are not dynamically dispatched and exhibit different behavior depending on the static type due to the shadowing issue.

> 
> You might argue that you mean just the methods declared only in the protocol extension - I see those, however as something that may help subclassing delegated instances. Example:
> 
> You have a root class representing some kind of a view - it has a `delegate` property. Then you decide to make a subclass and would like to introduce your own delegate methods on top of those offered by the superclass.
> 
> You can subclass the protocol, but Swift won't let you override the `delegate` property with a different type. So you can create a new property `mySubclassDelegate`, which is horrid, but kinda works.
> 
> The other option is to simply extend the original delegate protocol with additional methods with default implementation, which you should be able to override in your conforming class.
> 
> In code example:
> 
> protocol Delegate {
>    func myClassDidSomething(obj: MyClass)
> }
> 
> class MyClass {
>    weak var delegate: Delegate?
> }
> 
> extension Delegate {
>    func mySubclassDidSomethingElse(obj: MySubclass) { }
> }
> 
> class MySubclass: MyClass { }
> 
> This is where I see how this can be very useful in many areas not having it final.
> 
> Charlie
> 
>> Many moons ago, I was pushing to require a `final` keyword on protocol extension methods, which would prevent conforming types from providing their own implementations. It was probably the first thing I worked on. There were long arguments about whether and how you could override the `final`-ness, people kept clamoring for dynamic dispatch, and I ultimately wasn't able to produce a consensus before I had to turn my attention back towards paying work.
>> 
>> -- 
>> Brent Royal-Gordon
>> Architechies
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution