> On Sep 6, 2016, at 5:17 PM, Gerriet M. Denkmann <gerr...@mdenkmann.de> wrote: > >> On 5 Sep 2016, at 13:29, Quincey Morris >> <quinceymor...@rivergatesoftware.com> wrote: >> >> More globally, this sort of thing is not terribly idiomatic for Swift, >> because you’re trying to hide things that could get exposed other ways, for >> example, by “hostile” subclassing. The Swift-ier way would be to use a >> protocol instead of (or in addition to, but preferably instead of) the >> superclass. The protocol would “force” the subclass to define its own >> “onlyKnownBySubclass” locally. > > I do not think this would work for me. There are several subclasses and the > superclass contains lots of functions (some of which are overwritten by > subclasses). > If the superclass becomes a protocol then all this code had to be duplicated > in each subclass.
Swift protocol extensions can solve some of those problems. The protocol extension provides a default implementation to every class that conforms to the protocol. Each class may provide its own implementation that overrides the protocol extension's default implementation. -- Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime Wrangler _______________________________________________ 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
