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.k...@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.kl...@gmail.com> wrote:
>
> On 30 October 2017 at 02:54, Adam Kemp <adam.k...@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
>
>
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
