[swift-evolution] Protected access level / multiple class/struct/protocol APIs

[Thorsten Seitz]

> Am 31.03.2016 um 17:51 schrieb Joe Groff <jgroff at apple.com>:
> 
>> 
>> On Mar 30, 2016, at 11:31 PM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
>> 
>> 
>> 
>> Am 31. März 2016 um 05:15 schrieb Andrey Tarantsov via swift-evolution <swift-evolution at 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.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160331/60832c05/attachment.html>