> The problem with protected is that it provides virtually no protection at > all; you can trivially expose it in a derived class
+ > Extensions further dilute the enforceability of "protected", since anyone > would be able to use an extension to dump methods into a class's namespace > and access its supposedly-protected bits. I don't understand the need to protect against exposing something deliberately. We don't have a goal of restricting other developers, we're only saving them from accidental mistakes. > If a method was marked private in the base class, then it is very likely that > the name of the method, the design of its argument list and its return value > did not go through the same detailed design review as if the method would > have been meant to be part of the class’ interface from the start. So it’s > rather unlikely that increasing the visibility in an override is good idea > and in the spirit of the original writer of the private method. The design review and whether something is a good idea is left as a responsibility for those subclasses that choose to expose methods. The intentions of the original class author don't override the intentions of the subclass author. That said, I don't necessarily believe that the protected modifier is the best solution for the problems we're discussing. Some methods are not intended to be called at all, and protected doesn't solve that. A.
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
