> On Mar 30, 2016, at 11:31 PM, Thorsten Seitz <tseit...@icloud.com> wrote: > > > > Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution > <swift-evolution@swift.org>: > >>> 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. -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 swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
