> 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
