5 ms·
Sealing classes by default is troubling. I'm having a bad feeling about the future of Swift. I also think it's growing too big already.
by msie 11y ago
Sealing classes by default is troubling. I'm having a bad feeling about the future of Swift. I also think it's growing too big already.
- pjmlp 11y agoThe fragile base class problem shows that not sealing is also troubling, much more than sealing them.
- HillRat 11y agoIt can be, but the FBC problem is an architectural issue, whereas open/closed violation is a language issue. I feel that using the latter to deal with the former is potentially using a hammer to swat a fly on a glass door.
- wangii 11y agoGood point! however, in the case of Swift, it's just so closely related to UIKit and/or Cocoa.
- mpweiher 11y agoHmm...that problem that both Objective-C and Smalltalk don't have...
- pjmlp 11y agoAll OO languages suffer from it.
- msie 11y agoHow big of a problem is it really?
- pjmlp 11y agoQuite big for library writers. You cannot ever be sure how changes to the public / protected API from a class affects classes down in the inheritance tree. Specially bad is when methods that were never supposed to be overwriten change their semantics, leading to erratic behaviour on classes that have overwritten them.
- plorkyeran 11y agoObjective-C lets you add ivars without breaking subclasses (by computing and caching ivar offsets at runtime rather than compile time), but you still can't safely ever add methods to an existing class without running the risk of a subclass unintentionally overriding that method.
- austinz 11y agoYes, because moving from vtables to message passing eliminates a whole class of semantic errors whose genesis is independent of the implementation details of the language. Thanks for making this clear.
- deleted 11y ago[deleted]