<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div><br></div><div><br>Am 25.01.2016 um 23:03 schrieb Ilya Belenkiy <<a href="mailto:ilya.belenkiy@gmail.com">ilya.belenkiy@gmail.com</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class=""><blockquote type="cite" class=""><div class="">Why should the compiler enforce this? That’s my design decision.</div></blockquote></div><div class=""><div class=""><br class=""></div></div><div class="">It would enforce whatever design decision you make.</div></div></blockquote><div><br></div>It does enforce my design decision. If I decide to put several things into the same file this is a design decision stating that I want them being able to access their private members and other code outside of this file to not being able to do that. This is enforced.<div>Conversely if I don't want shared access, I put them into different files. Both design decisions are supported by the compiler.</div><div><br><blockquote type="cite"><div><blockquote type="cite" class=""><div class="">For the same reason the compiler does not enforce where I have to put „private“ (it can make suggestions like many IDEs do and offer fix-its, like „this method can be made private as it is not used outside the class“ or „this class can be put into its own file as its private methods are not used by other components in this file“.</div></blockquote><div class=""><div class=""><br class=""></div></div><div class="">But once you do put it, it enforces it, and that’s the whole point of having access control.</div></div></blockquote><div><br></div>Exactly and the compiler does support and enforce my decisions.</div><div><br><blockquote type="cite"><div><div class=""><blockquote type="cite" class=""><div class=""><div class="">No, there is a clear difference: making the type name part of the variable name enforces no compiler checks whereas putting something into different files does. </div></div></blockquote><div class=""><div class=""><div class=""><br class=""></div><div class="">Similarly, putting all of the source code in the same file is equivalent to no checks.</div></div></div></div></div></blockquote><div><br></div>No, that's the equivalent to not putting type information in the variable name.</div><div>In you naming example there is no difference, as nothing is enforced.</div><div>With putting things in different files the compiler enforces that private access is not possible. Just like I intended. If I put them into the same file I'm stating that private access is allowed, so there is nothing to enforce. </div><div><br><blockquote type="cite"><div><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class="">But you need to modify the file. With „local“ it is possible to break the class invariant without modifying the source code of a private method just by adding some public methods that call the private ones. Seems quite the same to me.</div></div></blockquote><div class=""><div class=""><div class=""><br class=""></div><div class="">No because then you change the class definition itself.</div></div></div></div></div></div></div></div></blockquote><div><br></div>You are changing code within the boundary of your (intended) access control. No difference there.</div><div><br></div><div>-Thorsten</div><div><br></div><div><br><blockquote type="cite"><div><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""> I would wish for a better name, though…</div></div></blockquote><br class=""></div><div class="">Me too. I wish “private” was “file internal” and “local” could be “private”. But the right name is already taken.</div></div></div></div></div></div></div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 4:44 PM, Thorsten Seitz <<a href="mailto:tseitz42@icloud.com" class="">tseitz42@icloud.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">Am 25.01.2016 um 20:33 schrieb Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">There would be no difference at all between local and private if you had one class per file.</div></div></blockquote><div class=""><br class=""></div><div class="">AND if this rule was enforced by the compiler. This would also have to be one extension per file, even if it’s one line of code.</div></div></div></blockquote><div class=""><br class=""></div>Why should the compiler enforce this? That’s my design decision.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class="">For the same reason the compiler does not enforce where I have to put „private“ (it can make suggestions like many IDEs do and offer fix-its, like „this method can be made private as it is not used outside the class“ or „this class can be put into its own file as its private methods are not used by other components in this file“.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: 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;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Since this rule is not enforced, at most, this is coding by convention. By the same reasoning, we could have just one type, object, and name every variable by including the type name we want it to be. No need for a strong type system. And anyone insisting that we need a type system would surely be wrong because there would be a very simple solution — just make the type name part of the variable name.<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div><div class="">No, there is a clear difference: making the type name part of the variable name enforces no compiler checks whereas putting something into different files does. </div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">And yet, Swift does have a strong type system. It should have strong access control for the very same reason: the compiler can enforce it and eliminate lots of human errors.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">It seems very very bold to me to say that Swift "doesn't support encapsulation" but that local would solve that problem.</div></div></blockquote><br class=""></div><div class="">And yet both statements are true: it is possible to break the class invariant right now without modifying the class source code, and “local” would solve that problem.</div></div></div></blockquote><div class=""><br class=""></div><div class="">But you need to modify the file. With „local“ it is possible to break the class invariant without modifying the source code of a private method just by adding some public methods that call the private ones. Seems quite the same to me.</div><div class=""><br class=""></div><div class="">That being said I have nothing against a „local“ access modifier but I personally don’t see a real need for it. I would wish for a better name, though...</div><div class=""><br class=""></div><div class="">-Thorsten</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 1:43 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">There would be no difference at all between local and private if you had one class per file. It seems very very bold to me to say that Swift "doesn't support encapsulation" but that local would solve that problem.</div><div class=""><div class=""><div class=""><div class=""><div class=""><br class="Apple-interchange-newline"><span class="" style="font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Félix</span></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 25 janv. 2016 à 13:16:45, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="">A language does not need to have strict access controls in order to be considered OO.<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">This is a matter of terminology. It still doesn’t change the fact that data encapsulation is a fundamental feature of object oriented programming that is currently not supported.<br class=""><br class=""><blockquote type="cite" class="">You don’t even need “classes” to do OO either.<br class=""></blockquote><br class="">In this terminology C is also object oriented. You can have opaque pointers to structs with functions around them. Swift current support for data encapsulation is exactly like that. But people don’t do this kind of programming in C precisely because the compiler can provide a lot more help than this.<br class=""><br class=""><blockquote type="cite" class="">This really seems like an academic problem vs a pragmatic problem.<span class="Apple-converted-space"> </span><br class=""></blockquote><br class=""><br class="">It’s very pragmatic. With properly marked access level and well designed interfaces, the class implementor may rely on the compiler to ensure that the class invariants / internal state will not become corrupt. Without it, the code is much more likely to break due to human error. It’s the same reasoning as with having ARC rather than doing manual retain / release and having destructors that are called automatically instead of calling cleanup code manually.<br class=""><br class=""><blockquote type="cite" class="">There’s also no concept of “friend” in Swift either<br class=""></blockquote><br class="">file based access level is a good solution for this. But it’s not a solution at all for real data encapsulation.<br class=""><br class=""><blockquote type="cite" class="">On Jan 25, 2016, at 12:09 PM, David Owens II <<a href="mailto:david@owensd.io" class="">david@owensd.io</a>> wrote:<br class=""><br class=""><br class=""><blockquote type="cite" class="">On Jan 25, 2016, at 4:47 AM, Ilya Belenkiy via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""><blockquote type="cite" class="">Data encapsulation is indeed one of the cornerstone of OO, but every design decision is a trade-off. Is Python not object-oriented because they lack a private keyword, and have the convention of marking internal items with a leading underscore?<br class=""></blockquote><br class=""><br class="">Then Python has the same problem. A language that *supports* OOP should not leave such an important part of OOP to coding by convention.<span class="Apple-converted-space"> </span><br class=""></blockquote><br class="">I think this where you are being lead astray. A language does not need to have strict access controls in order to be considered OO. Languages like C#, Java, and to some extent, C++ tend to make people think this. You don’t even need “classes” to do OO either.<br class=""><br class=""><blockquote type="cite" class=""><blockquote type="cite" class="">The best anyone can do is make the breaking of encapsulation an explicit choice. I’m intuiting that you think that writing code into the file where the class was defined is not explicit enough.<br class=""></blockquote><br class="">Right now, it’s impossible to make the distinction: is something truly private or can be used safely in the same file? The language has no way of expressing it. The class internal state is not encapsulated outside the bounds of the class.<br class=""></blockquote><br class="">This really seems like an academic problem vs a pragmatic problem. There’s also no concept of “friend” in Swift either, which is another construct that would have be invented to allow the “private” things to be used by others elsewhere.<span class="Apple-converted-space"> </span><br class=""><br class="">-David<br class=""></blockquote><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""></div></div></div></div></div></div></blockquote></div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div></div></blockquote></div><br class=""></div></blockquote></div></body></html>