Sent from my iPad
> On May 21, 2016, at 7:05 AM, Charlie Monroe via swift-evolution > <[email protected]> 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-@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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
