Please, almost anything but going back to the horrible Objective-C pattern of private headers (that end up included on in the implementation files) :/.
Seriously, that was always my issue with that blog post, assuming that the Objective-C way of dealing with this issue was something worth moving forward and not a path to massively improve upon or to avoid. Sent from my iPhone > On 20 Feb 2017, at 08:30, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > >> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution >> <[email protected]> wrote: >> >> A third point (which is a bit more complex/convoluted) is that fileprivate >> remained an essential language feature because it allows implementation in >> extensions, and allows a simple “friend”-like feature where types that need >> access to implementation details due to higher coupling could be bundled >> into the same file. Outside of a desire of a scoped ‘private’ simply to >> match the behavior of certain other languages, private is used to hide >> implementation details from other parts of a file, while file private >> exposes them within the file. >> >> There is a potential that file-private can lead to an explosion of >> complexity due to a large amount of “friendly types” being bundled into the >> same file. In that sense, ‘private’ was wrong because it was adding >> complexity at the file level, when really a new access level would possibly >> have been more productive to define at the at the small-group-of-files level >> - either via a friend access level or submodules. We still have the >> potential of unmanageable files due to friend types, but any additional >> access levels to aid with this problem would have to be weighed against a >> now significantly more complex access model including file and scoped >> private. In that sense, the inclusion of scoped private may indeed be >> harmful in that it increases the challenge of much more useful access levels >> being added to the language. > > This is the core of what I have been saying. If we don’t address this need > of “friendly types” in a swift-y way, we will have to keep coming back to the > drawing board (either for “friend” or “protected” or “submodules”). I really > like swift 2 private, but it did cause long files because all of the > extensions and friends had to be stuck in the same file. What we are really > missing is something that has the connotation similar to private, but allows > access where needed. > > I agree with most of what was said in this blog post from the swift devs: > https://developer.apple.com/swift/blog/?id=11 > > The main exception is that I disagree that ‘internal’ maps to the ObjC case > where a second header was used (it doesn’t, and that is what is causing all > of this trouble). Because internal is the default, it feels much too easy to > accidentally use parts of a type which should only be used by > extensions/subclasses/friend types. Remember, in an app (as opposed to a > framework), internal is basically equivalent to public. With the second > header, users of the contents of that header had to explicitly include it, > which meant there was no chance of accidental use. > > What we need is something which maps to that second header case while still > keeping everything conceptually simple and swift-y. > > Thanks, > Jon > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
