> * What is your evaluation of the proposal?
+1, with bikeshedding.
To me, “subclassable” does not imply “public.” If I hadn’t read this proposal,
I would be likely to declare an internal class subclassable, and then be
shocked when it was exposed as public!
If it’s part of my public API, I want to see the word “public” on it. That
should not be implicit under any circumstances. I strongly prefer any one of
these to the standalone “subclassable:”
• public(subclassable)
• public(open)
• public(extensible)
The extra verbosity is tolerable because subclassability by design is (should
be!) the exception, not the rule.
> * Does this proposal fit well with the feel and direction of Swift?
Yes, it fits two patterns of Swift’s general design:
if one choice is the default, it is the safer one; and
consequential design decisions are explicit. Implicitness is reserved for
obvious / redundant information that becomes noise and interferes with
readability.
To that end…
> * Is the problem being addressed significant enough to warrant a change to
> Swift?
…open public classes run against general precedent in the language, so yes.
As programmers grow used to Swift, they will increasingly lean on the compiler
to prompt them when there is an important type design issue to consider, or
when they are doing something that compromises type safety. The absence of a
compiler warning becomes important information.
This means that making open classes the default is not just aesthetically
suboptimal; it is actively misleading.
> * If you have used other languages or libraries with a similar feature, how
> do you feel that this proposal compares to those?
No. In all the OO languages I’ve used, classes are open by default. That raises
a question: is this really a good idea? Aren’t we ignoring established
precedent? What about all the unauthorized subclassing we’ve done in the past?
I’m sympathetic to those accustomed to Objective-C, Ruby, Javascript, Python,
and other languages with more fungible type systems who argue that it’s
unreasonable to expect us all to use classes only as library authors intend.
Monkey patching has saved many a day, they’d say. And it’s true, it has! I rely
on it.
My counterargument: the ecosystem is changing.
In the era of increased open sourcing, easy forking, and more community-driven
development, this concern is less severe than it used to be. I rarely use any
closed-sourced libraries for iOS development. If I need to tweak some library
and non-subclassibility is getting in the way, then I can fork it — and perhaps
even contribute my changes back to improve the upstream project. In an open
source world, “closed by default” makes a lot more sense.
The big exception to this is Apple itself, and the direction of this proposal
implies a large cultural shift in how Apple deals with its developer community.
Having the Swift language so aggressively prevent the dubious, brittle,
bad-idea-but-it-gets-the-job-done workarounds that the Obj-C runtime allowed
means that Apple’s platforms are going to have to be more consciously
extensible, more transparent in their design decisions, and more responsive to
unanticipated needs. This community right here is an exemplar.
Here’s thing: this big shift goes far, far beyond this proposal. Swift already
rules out most any form of messing with a library’s assumptions about its own
design. With or without the proposal, Apple is already getting on board with
the new regime of stricter typing and more hermetically sealed libraries.
They’re already going to have to make API design decisions about how and where
extensibility is allowed with unprecedented caution.
This proposal hardly alters that tipping balance; it just removes a design
inconsistency.
> * How much effort did you put into your review? A glance, a quick reading, or
> an in-depth study?
I read the proposal carefully, the discussion thread not at all.
Cheers,
Paul
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
