[swift-evolution] Make access control private by default.
rjmccall at apple.com
Thu May 19 13:18:44 CDT 2016
> On May 15, 2016, at 12:15 PM, Knut Lorenzen via swift-evolution <swift-evolution at swift.org> wrote:
> I think internal as default is bad, because it discourages encapsulation.
> Building scalable software components relies on hiding implementation details to create layers of abstraction. It’s a fundamental principle of object-oriented software design. Most other OOP languages have private default.
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.
> The linked doc doesn’t explain the advantages of internal as default in detail:
>> By default, most entities in a source file have internal access. This optimizes for the most common case—a single-target
>> application project—while not accidentally revealing entities to clients of a framework module.
> Optimizes for what? Build time? Brevity?
Convenience. Programs are free to completely ignore access control if they want. That's also pretty good for teachability.
Access control matters most for people organizing their code into libraries. Ultimately, we expect libraries to be packaged as independent modules (that can still be built directly into your application without dynamic cost, of course). An internal declaration is private to the module, 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.
>> Have your read
>> I prefer the current rationale behind "internal" by default.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution