<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=""><div><blockquote type="cite" class=""><div class=""><span 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;" class="">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=""><p style="margin: 0.0px 0.0px 0.0px 0.0px" class="">I guess you are making fun, but actually, good old Objective-C messaging works just that way:</p><p style="margin: 0.0px 0.0px 0.0px 0.0px" class="">You can call all those dangerous and forbidden private methods easily...</p><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></body></html>