Hacker News Reader

Comment by pjmlp | Hacker News Reader

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

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.

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.

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