[swift-evolution] [Returned for revision] SE-0117: Default classes to be non-subclassable publicly
2th at gmx.de
Fri Jul 15 04:41:40 CDT 2016
> does it make sense to require every member to be marked as “overridable” in order to be overridden by an open subclass outside of the current module?
Despite of probably being one of the most passionate defenders against adding restrictions on subclassing, I've to accept the clear statement made by the core team, so the imho only consequent answer to this question is requiring overridable on every single method:
- Whatever the perceived benefits of forbidding subclassing are, they are the same for each specific method
- It is the same principle that is applied to access control
For me, "open" has a tiny disadvantage, because I tend to read it as a verb, but it's most likely the best choice, and I recommend to re-use it and drop overridable:
- open is shorter
- open is less confusing
- access control follows the same principle of reuse
If the goal is taken serious, imho it is also questionable wether it is good to allow writing public properties without explicit rights to do so: It's a similar situation (you can read but not write vs. you can call but not override), and there is the proven template of default file access rights in UNIX.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution