[swift-evolution] classprivate protection level?

[Mike Kluev]

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".

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
    ....



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/b47fc733/attachment.html>