> On Sep 6, 2016, at 5:17 PM, Gerriet M. Denkmann <[email protected]> wrote: > >> On 5 Sep 2016, at 13:29, Quincey Morris >> <[email protected]> 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 [email protected] <mailto:[email protected]> Runtime Wrangler _______________________________________________ Cocoa-dev mailing list ([email protected]) 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 [email protected]
