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

[Dietmar Planitzer]

> On Mar 29, 2016, at 18:28, Joe Groff <jgroff at apple.com> wrote:
> 
> 
>> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> 
>>> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Well that would be true if we assume that protected would work that way. Considering that this:
>>> 
>>> private class A { … }
>>> 
>>> public class B : A { … }
>>> 
>>> is not allowed in Swift, I don’t see a good reason why an override of a protected method should be allowed to upgrade the access level to public. On the other hand this:
>>> 
>>> public class A {
>>>  private func foo() {
>>>      print("A")
>>>  }
>>> }
>>> 
>>> public class B : A {
>>>  public override func foo() {
>>>      print(“B”)
>>>  }
>>> }
>>> 
>>> happens to actually work if both A and B are defined in the same file - which is rather unexpected. I would have expected that Swift would in general not allow overrides to upgrade the inherited access level. Eg exposing semantics which is embodied in a private or protected method should require a conscisous design decision and should require the designer to introduce a separate method name which is part of the public API. The public method can then call through to the private or protected method as needed.
>> 
>> That would still be a toothless restriction, since a subclass could define a new method:
>> 
>> public class B : A {
>>  public func foo_() {
>>      super.foo()
>>  }
>> }
>> 
>> From an interface perspective, there's no difference between a subclass defining a new method or overriding a method that happens to be private to the base 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.

That is true assuming that Swift would allow an extension to call a protected method. But I don’t see a strict requirement that Swift would have to allow this.

There are two variants of extensions that are useful:

a) extension is used by the producer of a type to break up a large implementation into smaller pieces: in this case the implementor writes those extensions and in this case you can argue that an extension should allow the code writer to do everything that he can do in a base type. Eg allow the definition of stored properties and allow the calling of protected methods (and likely private methods too). Swift doesn’t currently really support this. Ideally it would be possible to put each extension into a separate file and things like accessing private members would still work.

b) extension is used by a consumer of a type to extend the type after the fact: in this case it makes sense that an extension comes with certain restrictions. Eg you can not add stored properties (which especially in the case of value types could change the nature of the value type drastically) and you can not call private or protected methods. This is what Swift’s extensions are today.


Regards,

Dietmar Planitzer

> -Joe