Hacker News Reader

Comment by msie | Hacker News Reader

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.

View on HN

The fragile base class problem shows that not sealing is also troubling, much more than sealing them.

It 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.

Good point! however, in the case of Swift, it's just so closely related to UIKit and/or Cocoa.

Hmm...that problem that both Objective-C and Smalltalk don't have...

Objective-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.

All OO languages suffer from it.

How big of a problem is it really?

Quite 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.

Yes, 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.

Reply on news.ycombinator.com