> My answer is this: There is nothing magical about being a subclass that ought > to grant access to those methods.
There is - it's a family member that you let use your summer house. Without the metaphor, here is an example for this being useful: URLConnection subclass may want to update the URL in case of a redirect, but you don't really want to expose the setter for the URL to public. > For instance, if your subclass grows very complicated and you extract a > helper object, it's perfectly reasonable for that helper object to want to > access the "subclass-only" API. That's what "friend" classes are for in C++, similar concept would be applied here. > Contrarily, simple subclasses might not need that API, and exposing it to > them would be an unnecessary risk. And there are things which you don't > subclass at all which could benefit from being hidden away—think of the > Objective-C runtime, which has some parts which every app needs (like the > definition of `BOOL`) and othe _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
