<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>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:</div><div><br></div><div></div><div> Public means a change could break any code. </div><div><br></div><div> Internal means only code in the module can break so you can audit all usages in that module and fix as needed.</div><div><span style="background-color: rgba(255, 255, 255, 0);"><br></span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> File private means only code within the file can break so you only have to audit the one file.</span></div><div><br></div><div> 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.</div><div><br></div><div>What would a proposed new access level mean for which code has to be audited when making a change?</div><div><br></div><div> 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.</div><div><br></div><div> If any extension can access something within the same module then it’s the same as internal. You have to audit the whole module.</div><div><br></div><div>If your new access level doesn’t make a new bucket for what code to audit then it’s not adding any value.</div><div><br>On Oct 29, 2017, at 8:40 PM, Mike Kluev <<a href="mailto:mike.kluev@gmail.com">mike.kluev@gmail.com</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">On 30 October 2017 at 02:54, Adam Kemp <span dir="ltr"><<a href="mailto:adam.kemp@apple.com" target="_blank">adam.kemp@apple.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><span class=""><div></div><div><br></div></span><div>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. </div><br></div></blockquote></div><br></div><div class="gmail_extra">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?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Mike</div><div class="gmail_extra"><br></div></div>
</div></blockquote></body></html>