I have no problems with "protected" members being made accessible in subclasses 
or extensions because this requires conscious decisions and actions to extend 
the API.
Access levels are not there to protect against hacking, they are there to 
ensure that something can only be used through its given API. They are not 
there to restrict extending that API.

Having said that I'd love to have "protected".

-Thorsten 

> Am 30.03.2016 um 03:28 schrieb Joe Groff via swift-evolution 
> <[email protected]>:
> 
> 
>>> On Mar 29, 2016, at 6:18 PM, Joe Groff via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> 
>>> On Mar 29, 2016, at 6:04 PM, Dietmar Planitzer via swift-evolution 
>>> <[email protected]> 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.
> 
> -Joe
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to