> On May 15, 2016, at 12:15 PM, Knut Lorenzen via swift-evolution > <swift-evolution@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. John. > > Knut > >> Have your read >> https://github.com/apple/swift/blob/master/docs/AccessControl.rst? >> >> I prefer the current rationale behind "internal" by default. >> >> Stephen > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
