> On 19 May 2016, at 19:18, John McCall <rjmcc...@apple.com> wrote: > > That is not at all true. The dynamic OOP languages do not, as a rule, have > any access control at all. Java and C# default to package access, which is > analogous to internal. C++ is, as always, complicated and different.
Class members are private by default in both Java and C#. As are ivars and selectors in Objective-C (the latter having to be redeclared in the header file for module-wide access). Swift definitely gives greater default scope to class members in comparison to other OOP languages. > Convenience. Programs are free to completely ignore access control if they > want. Convenience can also be lead to shortsightedness and poor code structure. Programmers will be tempted to modify a property or call a function from anywhere just because can, instead of thinking twice because they need mark it as internal first. And when reading someone else's code, it is hard to tell the scope of properties and functions if they are internal by default. One has to tediously examine them one by one for project-wide use. > That's also pretty good for teachability. How so? I think especially beginners need to learn the importance of encapsulation. Hiding implementation details in order to create layers of abstraction is a fundamental concept of software design. > and so the default rule still provides encapsulation by default at the > library boundary. But not all code is library code, and we don't want to > burden application development with having to specify access control > everywhere. Following that rationale, why does private even exist? Seems inconsistent Knut _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
