<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><blockquote type="cite" class="">On May 30, 2016, at 11:23 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</a>> wrote:<br class=""></blockquote><div><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><span class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Couldn’t you use the same reasoning to claim there shouldn’t be access control at all? Just add documention on methods you want to mark private telling users of the library not to call them!</span></div></blockquote></div><div class=""><div style="margin: 0px;" class="">I guess you are making fun, but actually, good old Objective-C messaging works just that way:</div><div style="margin: 0px;" class="">You can call all those dangerous and forbidden private methods easily...</div><div class="">Writing special comments is just one way to document APIs; having no (official) documentation at all is documentation as well ("don't use this!").</div></div><div class=""><br class=""></div><div class="">Most technical limitations can be cracked by skilled hackers (working around "protected" is especially easy), so I really think that (for example) declaring a method "final" says "I don't want this to be changed in a subclass" in the first place, and the compiler error that is triggered when you try to break the limitation is little more but a remainder.</div><div class=""><br class=""></div><div class="">Enforcing limitations using hacks causes confusion, so I would never use such tricks in production code.</div></div></div></blockquote></div><br class=""><div class="">The purpose of access control isn’t really to keep out malicious users, though, it’s to prevent accidental misuse and clarify the interface.</div><div class=""><br class=""></div><div class="">One nice vector for accidental misuse is autocomplete. Even if layoutSubviews() has a great big // DON’T USE!!! in the documentation, it’s possible that someone is trying to remember the name of the API they need to use to tell the OS something needs to update its layout, so they type “layout” into the code editor, and lo and behold! Here’s something called layoutSubviews() that sounds like the sort of thing we want. And so it goes. A protected modifier in the language would prevent things like this.</div><div class=""><br class=""></div><div class="">Charles</div><div class=""><br class=""></div></body></html>