Hi Brian, is the override proposal still in the making? Kind Regards, Björn
On Thu, Mar 23, 2017 at 4:24 PM, Brian King via swift-evolution < swift-evolution@swift.org> wrote: > Hey Iman, This is a known bug SR-103. It certainly has caught a few people > off guard. Dale Buckley is working on an evolution proposal that would > allow the bug to be fixed: > > Proposal: > https://gist.github.com/dlbuckley/1858a7c0b5c027248fe16171d23ba01d > > Conversation on the Proposal: > https://lists.swift.org/pipermail/swift-evolution/ > Week-of-Mon-20170313/033787.html > > The only work around at this time is to make sure that your base class > implements all methods in the protocol. > > Brian King > > > On Thu, Mar 23, 2017 at 11:15 AM, Iman Zarrabian via swift-evolution < > swift-evolution@swift.org> wrote: > >> Hi, >> This is my first contribution to this list so I’m a little nervous. >> I’ve been refactoring some code in one of our internal frameworks and >> noticed something I didn’t noticed about protocols before. >> Maybe I’m missing the big picture here but I’ll expose the issue to you >> anyway. >> Consider these protocols and classes declarations : >> >> protocol Foo { >> func bar() >> func specificBar() >> func moreBar() >> } >> >> extension Foo { >> func specificBar() { >> print("default specificBar implementation") >> } >> } >> >> extension UIView: Foo { >> func bar() { >> print("uiview default bar") >> specificBar() >> moreBar() >> } >> >> >> func moreBar() { >> print("UIView is foo compliant and implements moreBar function") >> } >> } >> >> class CustomView: UIView { >> func startJob() { >> bar() >> } >> >> >> func specificBar() { >> print("CustomView specific bar implementation") //This is the >> implementation I want for specificBar but this is not the one picked at >> runtime. >> } >> } >> >> >> let view = CustomView() >> view.startJob() >> >> //Prints : >> //uiview default bar >> *//default specificBar implementation* >> //UIView is foo compliant and implements moreBar function >> >> I was wondering if it is a good idea to give the CustomView class the >> power to be more specific about it’s parent protocol adoption. >> >> It seems to me that implementation of a protocol method cannot be easily >> changed by subclasses of the class that actually adopts the protocol in the >> first place. IMO one way to achieve the kind of specialization I’m trying >> to do is to create two protocols and another would be to implement a >> version of specificBar in the superclass (UIView here) >> >> But does it make sense to consider some kind of cherry picking (with a >> new keyword) for those methods we want to implement more precisely than the >> one provided on the protocol extension? >> Consider this new code for CustomView : >> >> class CustomView: UIView { >> func startJob() { >> bar() >> } >> >> >> override adoption func specificBar() { //or override protocol => >> implements a method from a protocol adopted by the superclass >> print("CustomView specificBar implementation") >> } >> } >> >> let view = CustomView() >> view.startJob() >> >> //Would print : >> //uiview default bar >> *//CustomView specificBar implementation* >> //UIView is foo compliant and implements moreBar function >> >> I would appreciate your feedback. >> >> -- >> Iman Zarrabian >> @imanzarrabian >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution