<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 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="color: rgb(0, 0, 0); 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; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><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="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></div></div></div></div></body></html>