[swift-evolution] [Review] SE-0117: Default classes to be non-subclassable publicly
Kevin Lundberg
kevin at klundberg.com
Tue Jul 5 19:54:42 CDT 2016
* What is your evaluation of the proposal?
-1 as is. I do not want to be constrained by authors of libraries or
frameworks into interacting with a system in only the ways they forsee.
By making the default be non-subclassable, if a designer does not put
thought into all the ways a class can be used then I as a consumer of
the library am penalized.
Another point I can think of is mocking in tests. I'm unaware of any
fully featured mocking solution in swift, and subclassing a class to
override methods for mocking purposes is one way to make unit tests work
with third party dependencies. If a class was not designed for
subclassing, then writing tests where the class's behavior needs to be
suppressed would not be possible. One could write a facade between the
system under test and the dependency, but if the dependency is only used
in a one or a few places then that becomes a lot of extra boilerplate
code to write, especially if that process needed to happen many times.
I understand the value of this behavior though, and I would prefer that
this behavior becomes opt-in instead of opt-out. One possible
illustration (not meant as definitive syntax):
public(final) class Thing {}
public(final) func doSomething() {}
where the symbols are publicly final, but lesser access scopes are open.
* Is the problem being addressed significant enough to warrant a change
to Swift?
Some change here would be welcome, but as I said I think the inverse
situation is a better solution.
* Does this proposal fit well with the feel and direction of Swift?
It partially does, as giving developers tools to protect things they know are critical or sensitive is a good idea, but it should not come at the cost of a client's freedom to use a library in ways that fall outside of the original predictions of the author.
* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
The main other language I've used is C# that does this at the method
level (where overridable methods must be marked with the `virtual`
keyword).
I've had issues before when working with third party C# code where the
author didn't declare a method as virtual, but the problem I was trying
to solve required me to override that method. Luckily the code was open
source, so I just embedded and edited the source into my project instead
of using the prebuilt binaries, but that becomes a maintenance headache,
and it is not possible for components that do not make the source available.
* How much effort did you put into your review? A glance, a quick
reading, or an in-depth study?
In depth study, and some participation on some of the initial threads
about this topic.
More information about the swift-evolution
mailing list