Ah, I see what you're saying, that the private(call) in B implies that B can call it. It's a semantic issue. Well, if you want to have the subclass's implementation declared as unavailable(call), that works.
Charles
···
On 2016-01-12 23:16, Michel Fortin wrote:
Le 12 janv. 2016 à 22:52, cocoadev@charlessoft.com a écrit :
In any case, the most common use case, and the one that IMO makes the most sense, would be to define the overriding method as private(call) as well.
Ok then, that's the lie. (Not that you're lying, but the syntax you
propose is a lie.)When I read `private(call)`, I read it "private visibility for calling
the method", just like `private(set)` means "private visibility for
the setter". A private visibility limits the usage to the current
file. And the usage being limited to the current file is the ability
to call the method.When you apply `private(call)` in the base class context, the method
is callable only from the current file (thus the call ability is
private). That's exactly what's needed. All is good.But when you apply `private(call)` at the override point, you want the
method to not be callable from the current file. The syntax is saying
the call ability is private (limited to the current file), but that's
simply not true. What you really want to say here is
`unavailable(call)`, but that does not exist.