On Sep 6, 2016, at 23:26 , Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote: > > Anything to be done here? Or should I just forget about protocol extensions?
There’s nothing really wrong here, it’s just that it doesn’t work like you think. There is no *inheritance* of protocol default implementations, which means there is no overriding either. You get whichever protocol extension function the compiler thinks is visible at that point in the source code (which is, I’m sure, deterministic, but I couldn’t tell you the rules when you have multiple uses of the same function names like you do), and there’s no run-time dynamism. That’s why I said earlier you can’t just translate an inheritance design into a protocol composition design. There is no semantic equivalence. Trying to get around that by creating a mixed inheritance/protocol design turns out to be much harder, not easier, than using one or the other exclusively. If you’re used to inheritance, it’s actually quite hard to re-tool your brain to figure out how to solve the problem with protocols. In general, the solution has quite a different structure. Rather than asking how to implement an inheritance pattern of shared code (which, if you think about it, you’ll realize is an implementation decision, not a design decision, although the distinction is virtually erased by your familiarity with coming up with inheritance patterns), you need to consider what behavior each subclass has, abstracting out shared behavior into a series of protocols that are adopted as necessary to give the right *combination* of behaviors for each subclass. It’s a “horizontal” composition, not a “vertical” layering. If you have no time for exploration, then stick with inheritance and proceed in the usual way. (Apart from initialization, inheritance in Swift should be no less capable than inheritance in Obj-C.) If you’re prepared to take your API apart bit by bit, then play around with composition until you figure out how it all fits together. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
