To be clear, I agree that there is a problem. I just perceive it as a documentation problem more than as an access control problem.
There are at least 2 other proposals that suggest(ed?) a more complex access control model (`private(extension)`, `private(objc)`), and I don't like adding exceptions to `private`.
Félix
···
Le 12 janv. 2016 à 16:43:39, Charles Srstka via swift-evolution <swift-evolution@swift.org> a écrit :
On 2016-01-12 13:50, Michel Fortin wrote:
Le 11 janv. 2016 à 19:53, Charles Srstka via swift-evolution >> <swift-evolution@swift.org> a écrit :
What do you think?
The idea looks good to me on the surface. But the details are awkward.
First, if you can't call the super implementation from an override,
there is no need to require that the overriding function be
private(call) because all it will contain is client code that can't
call the library's implementation. So the derived class can make the
function more visible by reimplementing it.My thinking is that if the subclass wants to make the functionality behind the method more visible, it's better to just spin it off into a separate method rather than ask callers to get used to calling a method that, according to the API contract of the superclass, is more an implementation detail than a part of the external interface.
But that's not the common case. In general you want to allow the
overriding function to call the super implementation. So...
Second, if you allow a call to the super implementation from an
override, then you need to make that overriding function uncallable by
anyone. Only the base class can call it using virtual dispatch. You
can't call it even from the same file, so it's *less visible than
private*.
That's a bit weird.It may be a bit weird, but it is what the API contract is already asking the class to do. It's just that currently, it's not enforced other than in documentation.
I should point out that we, essentially, already have methods like this; Swift initializers, unlike init methods in Objective-C, are similarly invisible; they cannot be called by any other code, even in the same file, unless that code is marked as a convenience initializer. Deinit, likewise, can't be called by anything except for the Swift runtime itself.
Charles
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution