[swift-evolution] private(call) and internal(call)

[cocoadev at charlessoft.com]

On 2016-01-12 11:58, Félix Cloutier wrote:
>> Le 12 janv. 2016 à 02:11:07, cocoadev at charlessoft.com a écrit :
>> 
>> Unless we are talking about someone hacking their way in via C or 
>> assembler or something, no, they don't have the means to do so. And if 
>> we *are* talking about hacking, then that's impossible to prevent, 
>> anyway, if someone is *really* determined. I mean, even if the stupid 
>> thing is inlined, you could still disassemble the thing and 
>> copy-and-paste out the relevant part. Making things 100% bulletproof 
>> is not the goal, and if it were, we would have been publishing every 
>> single API, private and public, in Objective-C, since in that language 
>> it was staggeringly easy, even for a relative neophyte, to find and 
>> call private methods on pretty much anything. Despite that, we still 
>> found it useful to hide things in private headers and implementation 
>> files, which suggests that access control does have a use beyond the 
>> linker level after all.
> 
> class A {
> 	private(call) func logicYouShouldImplementButNotCall() {
> 	}
> }
> 
> /* other module */ class B {
> 	private(call) override func logicYouShouldImplementButNotCall() {
> 		iActuallyWantToCallItWhyWontYouLetMeDoIt()
> 	}
> 
> 	func iActuallyWantToCallItWhyWontYouLetMeDoIt() {
> 		/* snip */
> 	}
> }

B can also expose any private method or property that it has via a 
separate method.

class B {
     private func mineAllMine() {
         ohNoes()
     }

     func ohNoes() {}
}

How is that new?

Anyway, if the author of the class did that, I'd assume they had some 
reason for it. And if there *were* some reason to expose the logic 
backing the primitive method, I'd say it's better to create a new public 
method anyway to make your intentions clear, rather than asking users to 
call the method that according to your superclass's API contract isn't 
supposed to be called.

Class B cannot call Class *A*'s implementation of it, nor will a user of 
both these classes mistake logicYouShouldImplementButNotCall() as 
something they should use as an access point.

> I'm not in favor of complexifying access control for the sake of
> documentation. The first two goals can be implemented with just a
> little more collaboration between tools and documentation and you can
> get 90% of the way there for the third one as well.

Again, things like -[NSView display] have long been a stumbling block 
for newbies who often don't realize that they should be calling 
-setNeedsDisplay: instead until someone tells them. We can make our APIs 
more intuitive, and we should.

Charles