> 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.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
