I agree with Nevin’s points in large strokes, but I don’t think large files are the end of the world. I think an important takeaway idea from all the access control threads is that we need not provide facilities in the language to support antipatterns; we should more focus on how to encourage good patterns better.
On the face of it, I’m excited by the proposal; even if this isn’t the answer, we should seek to go down any road that removes fileprivate (and I mean remove - not just a new spelling) but preserves aspect the feature to please whatever it is that people like about that feature. > On Feb 21, 2017, at 7:36 PM, Nevin Brackett-Rozinsky via swift-evolution > <swift-evolution@swift.org> wrote: > > This proposal is definitely *not* what I want from a submodule system, > because it will exacerbate the problem of developers stuffing large amounts > of code into a single file. > > The “fileprivate” keyword already encourages long files, because there is no > way to split up related components into separate files while retaining > encapsulation. And scope-based “private” is even worse of an offender, > because it requires nesting code inside the same *type declaration*, so you > can’t even benefit from extensions. > > To my mind, any submodule system for Swift should be designed to relieve the > pressure for long files, and make it easy to group tightly related files into > a single unit with shared visibility. That way developers can easily organize > their code into smaller files while utilizing Swift’s pattern of providing > protocol conformances in extensions and keeping implementation details hidden > from the rest of the module at large. > > For example, one possible design would enable us to replace both “private” > and “fileprivate” with a single new access level—probably spelled “private— > which restricts visibility to just the current submodule. That way it > provides all the benefits of “fileprivate” (implementation hiding and the > ability to use extensions) while also allowing code to be placed in separate > files rather than one large file. > > Nevin > _______________________________________________ > 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
