> Am 31.03.2016 um 17:51 schrieb Joe Groff <[email protected]>: > >> >> On Mar 30, 2016, at 11:31 PM, Thorsten Seitz <[email protected]> wrote: >> >> >> >> Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution >> <[email protected]>: >> >>>> 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. >> >> Totally agree, access control is not intended to be protection against >> hacking. If a derived class wants to expose something then that is >> absolutely fine as long as it makes sense for the derived class. > > My point is that "protected" *isn't* access control. If we added it, it would > have to be as an independent modifier. Private/internal/public fundamentally > affect semantics—private and internal code is only accessible within a > module, so we have full knowledge of their use sites at compile time and can > be more permissive with extensions, implicit constructors, and other > features. Public API can be used by arbitrary unknown external code so > requires additional restrictions to ensure that the interface remains stable. > "Only usable by subclasses" is an orthogonal axis to this—if a method is only > usable by external subclasses, it requires all of the same restrictions as > public code. If a method is only usable by subclasses within the module, it > can behave like a private or internal method.
Ah, now I understand what you mean! Thanks for clarifying! I agree that this has to be taken into account when defining what „protected“ means and how it interacts with other parts of the language. -Thorsten > > -Joe > >> >> >>>> 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. >> >> Exactly. >> >> -Thorsten
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
