[swift-evolution] classprivate protection level?

[Adam Kemp]

> On Oct 29, 2017, at 9:22 PM, Mike Kluev <mike.kluev at gmail.com> wrote:
> 
> Module1
> 
>     Class A in it's own file
>     extension A in it's own file
> 
>     Class B in it's own file
>     extension B in it's own file
> 
>     Class C in it's own file
>     extension C in it's own file
> 
> Module 2
>     ....
> 
> obviously i do not want guys from team B and C accessing anything "team A private".

Then your proposal cannot help you accomplish that goal. If any extension of class A can access a method then someone writing code in the same file as B or C can write an extension of class A and expose it to other code in the same file as B or C. That means when you are making a change to that method you have to assume that there may be code relying on it, and you have to audit that code.

It’s worse than that, though. If that method is accessible even to extensions in other modules then that means any external client of this module could also rely on that behavior, and that means you cannot safely change it at all. You have effectively made it public. You have lost all control. It is no longer encapsulated at all.

When you choose an access level you are deciding which code you are allowing to depend on it, and thus which code you will have to fix if you change it. If a change might break any client of the whole module then it’s public. You’re only fooling yourself if you call it something else. 

> 
> is my understanding of your words then correct that you suggest to have this:
> 
> Module1
> 
>     Class A in it's own file
>     extension A in it's own file
> 
> Module2
> 
>     Class B in it's own file
>     extension B in it's own file
> 
> Module3
> 
>     Class C in it's own file
>     extension C in it's own file
> 
> Module 4
>     ....

No. There are two reasonable options:

1. Make it public. If it’s needed outside the module then this is an accurate description of its access level. 

2. Make it internal and accept that any code in the same module can access it. Again, that is effectively what your proposed scope allows anyway so internal is an accurate description of its actual access level. Call it what it is.

Either way the answer is basically the same: don’t obfuscate the effective access level and pretend you’re being strict when you’re really not. It’s like putting a lock on the door with the key hanging from the doorknob. You may as well just keep it unlocked. 

> 
> 
> 
>> On 30 October 2017 at 04:04, Adam Kemp <adam.kemp at apple.com> wrote:
>> Access levels exist for encapsulation. They don’t mean anything unless they actually allow you to reason about which code can break if you make a change. Given that, here is how each existing access level is useful:
>> 
>>     Public means a change could break any code. 
>> 
>>     Internal means only code in the module can break so you can audit all usages in that module and fix as needed.
>> 
>>     File private means only code within the file can break so you only have to audit the one file.
>> 
>>     Private means only code within the class or extensions in the same file can break so you only have to audit part of that one file.
>> 
>> What would a proposed new access level mean for which code has to be audited when making a change?
>> 
>>     If any extension can access something even across modules then that makes it the same as public. You can’t make any change without risking breaking a client.
>> 
>>     If any extension can access something within the same module then it’s the same as internal. You have to audit the whole module.
>> 
>> If your new access level doesn’t make a new bucket for what code to audit then it’s not adding any value.
>> 
>>> On Oct 29, 2017, at 8:40 PM, Mike Kluev <mike.kluev at gmail.com> wrote:
>>> 
>>>> On 30 October 2017 at 02:54, Adam Kemp <adam.kemp at apple.com> wrote:
>>>> 
>>>> That was my original point. This is what internal does. We don’t need any new access levels for extensions. Internal solves these use cases. Code in the same module can be maintained in lockstep so you can make things internal as needed for extensions. Anything beyond that is effectively indistinguishable from public so just call it that. 
>>>> 
>>> 
>>> if I have N big classes,  each split across M files to keep size manageable, do I need to have N different modules if i want to achieve a good separation between classes? (same level of protection that private gives for a class that fits in a single file) i.e. one module per one class?
>>> 
>>> Mike
>>> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171030/905d3cce/attachment.html>