<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Oct 30, 2017, at 10:57 AM, Mike Kluev <<a href="mailto:mike.kluev@gmail.com" class="">mike.kluev@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On 30 October 2017 at 17:22, Adam Kemp <span dir="ltr" class=""><<a href="mailto:adam_kemp@apple.com" target="_blank" class="">adam_kemp@apple.com</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word;line-break:after-white-space" class=""><br class=""><div class=""><div class="">The goal isn’t to entirely avoid having to audit any code while making a change. The goal is to allow you to reason about which code you would have to audit. A new access level should lead to a new bucket of code that needs to be audited, but none of the proposals here would do that. They’re all equivalent to existing access levels.</div></div></div></blockquote></div><br class=""></div><div class="gmail_extra">the new bucket would be "class and all of its extensions be them in the same file or in different files”.<br class=""></div></div></div></blockquote><div><br class=""></div><div>That’s not a new bucket. It is equivalent to either internal or public, depending on whether you want to extend this beyond the module boundary. The set of code you would have to audit is the same.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">back to your example with the locked door and the keys on the doorstep, i can violate "protected" in C++:</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">developer 1:</div><div class="gmail_extra">class Base { protected void foo(); }</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">developer 2:</div><div class="gmail_extra">class Derived: Base { public void not_so_protected_foo() { foo() }<br class=""></div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">but that doesn't mean that "protected" in C++ shall be ditched!</div></div></div></blockquote><div><br class=""></div><div>In terms of reasoning about code that might break, protected is equivalent to public. The only advantage to protected over public is that it tells clients how to properly use it.</div><div><br class=""></div><div>What does marking a method as “specialprivate” (my made up name for this new access level) tell clients about who can use it or how it can be used?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><br class=""></div><div class="gmail_extra">this is similar to what you said before about writing an extension and exposing the private functionality as public violating protection.</div><div class="gmail_extra"><br class=""></div><div class="gmail_extra">Mike</div><div class="gmail_extra"><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>