I didn’t say we should have headers, I said we need something that maps to those use cases in a swift-y way.
Just being able to mark something as internal to the type, and a way to opt-in to seeing those things within a particular file. Thanks, Jon > On Feb 20, 2017, at 12:39 AM, Goffredo Marocchi <[email protected]> wrote: > > 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] <mailto:[email protected]>> wrote: > >> >>> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution >>> <[email protected] <mailto:[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 >> <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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
