<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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I don't understand your conception of encapsulation. The way you're putting it, because of Swift's access modifiers, encapsulation is relative to whether you have access to the original source or not. </div></blockquote><div class=""><br class=""></div><div class="">It’s not *my* conception of encapsulation. There is only one: a class provides a public interface, and the internal state can be accessed only through that public interface. The only way to get to the private state is to modify the class itself. This is not the case with Swift — any code in the same file as the class can get access to the internal state and potentially break it.</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;"> The way you're putting it, because of Swift's access modifiers, encapsulation is relative to whether you have access to the original source or not. However, this is trivially true in any condition and whether Swift promoted a "private" or "local" access modifier would change nothing to it.</div></blockquote><br class=""></div><div class="">The difference is that with “local” you must change the class definition itself, and the change is very visible. With “private”, as long as the change is in the same file, the caller could accidentally (or deliberately) call an API that is meant to be private and break the object internal state.</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="">In my opinion, this solution will be confusing to a lot of people</div></div></blockquote><br class=""></div><div class="">That may be only because of unfortunate names for these access modifiers. What is now called “private” should really be “file internal” or something like that. And “local” should be “private”. But that name is already taken. Another alternative is to do the automatic renaming, but I didn’t want to overload the proposal with that. If this is the only issue, it can be solved very easily.</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="">the problem that it solves is many orders of magnitude less important than strong typing</div></div></blockquote></div><div class=""><br class=""></div><div class="">This is a matter of opinion. I think that it’s just as important, but it should be many orders of magnitude easier to implement.</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="">A "local" access modifier is not a breakthrough solution that will make it substantially easier to statically reason about programs to make them faster, provide refactoring tools, or help editing.</div></div></blockquote><br class=""></div><div class="">Not a breakthrough at all — it’s a basic feature that any language that supports OOP should have. But it does make it substantially easier to eliminate human error due to accidental misuse of APIs that are intended to be completely hidden and today cannot be.</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's a design tool intended for humans only, and it's extremely ambiguous with private.</div></div></blockquote><br class=""></div><div class="">It’s a tool for both humans and the compiler. Humans can clearly see the author’s intent, and the compiler can enforce it.</div><div class=""><br class=""></div><div class="">It’s not ambiguous at all: “private’ (really should be “file internal”) is to hide visibility in the same file. “local” is to hide it inside the class (or extension). The only ambiguous part is the naming. The original name (“private”) is unfortunate. I’d be happy to change it, but I am not sure if it’s possible at this point.</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="">A new programmer makes a class and asks you if fields and methods should be private or local. What do you tell him?</div></div></blockquote><br class=""></div><div class="">local, of course. Only the public class API should be exposed to the outside world. “private” is a trade-off, similar to “friend” in C++. Unless that trade-off is necessary, there is no need to use “private” the way it is today (if we had “local”).</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Jan 25, 2016, at 3:26 PM, Félix Cloutier <<a href="mailto:felixcca@yahoo.ca" class="">felixcca@yahoo.ca</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I don't understand your conception of encapsulation. The way you're putting it, because of Swift's access modifiers, encapsulation is relative to whether you have access to the original source or not. However, this is trivially true in any condition and whether Swift promoted a "private" or "local" access modifier would change nothing to it.<div class=""><br class=""></div><div class="">In my opinion, this solution will be confusing to a lot of people, and the problem that it solves is many orders of magnitude less important than strong typing. A "local" access modifier is not a breakthrough solution that will make it substantially easier to statically reason about programs to make them faster, provide refactoring tools, or help editing. It's a design tool intended for humans only, and it's extremely ambiguous with private.</div><div class=""><br class=""></div><div class="">A new programmer makes a class and asks you if fields and methods should be private or local. What do you tell him?<br class=""><div class=""><div class=""><div class=""><div class="">
<br class="Apple-interchange-newline"><span 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;" class="">Félix</span>
</div>
<br class=""><div class=""><blockquote type="cite" class=""><div class="">Le 25 janv. 2016 à 14:33:18, Ilya Belenkiy <<a href="mailto:ilya.belenkiy@gmail.com" class="">ilya.belenkiy@gmail.com</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 class=""><br class=""></div><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. 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><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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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 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;" class="">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. <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. <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. <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. <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></div></blockquote></div><br class=""></div></div></div></div></div></div></blockquote></div><br class=""></body></html>