I just finished listening to the latest episode of ATP where the hosts had an interesting discussion about the proposal to mark classes “final” by default in Swift. Let me first say that this whole topic is way over my head as a beginning programmer¹. However, I just wanted to touch on my surprise and confusion when one of the guys basically said that subclassing is kinda on its way out. My reaction in a nutshell was: wait, what? Subclassing is pretty much all I do. What’s the alternative?

Here’s a little snippet from the SpriteKit Programming Guide.

Note the last bullet point:

• You create custom scenes by subclassing the <a href="https://developer.apple.com/library/ios/documentation/SpriteKit/Reference/SKScene_Ref/index.html#//apple_ref/occ/cl/SKScene" target="_self" data-renderer-version="2">SKScene</a> class.

It’s so matter-of-fact, right? To me, that says: this is what you do; this is the programming pattern you use. Obviously, SKScene was designed to be subclassed. Most of the SpriteKit framework was, actually (see the entire section on “Use subclassing to create your own node behaviors” within SpriteKit Best Practices). Search the iOS developer library for the word “subclass” and see how often Apple gives specific advice on how to subclass one of their framework classes.

From the UIColor class reference:

Most developers should have no need to subclass UIColor. The only time doing so might be necessary is if you require support for additional colorspaces or color models. If you do subclass, the properties and methods you add must also be safe to use from multiple threads.

Don’t get me wrong: I understand that this proposal only concerns the default setting and that this doesn’t mean that Apple will automatically lock their frameworks down completely. But that’s kinda what the discussion was about on ATP, and well…I guess I just wanted to point out that in the case of games, subclassing is more or less essential. Heck, Apple’s brand new GameplayKit framework relies enormously on subclassing for its Entities and Components system. Basically, it’s expected that you’re going to subclass GKComponent for each separate behavior/functionality that you need to assign to an entity.

Anyway, all of this is to say that if this proposal is accepted, I would expect that more often than not Apple’s framework classes would be marked “not final”…or whatever the opposite of final is. It seems to me like they’re already very explicit about what they don’t want you to subclass, and that those things are few and far between. For example:

You must not subclass the NSIndexSet class.

Not a lot of room for confusion there. But I guess we’ll see what happens once the “NS” prefix is dropped and everything is rewritten with a Swiftier mentality. Maybe Apple will lock more things down. At this point, however, I just don’t see why they would, and making “final” the default seems like it would create more headaches and more work than anything else, with the benefit being a sense of additional safety that perhaps hasn’t proved to be necessary.