Ok, on this I can agree... and I will. It try to mention how judging things by how "Swifty" they are makes us seem like a cult... but then again we are programmers/engineers... that word may very well apply appropriately :).
Sent from my iPhone > On 20 Feb 2017, at 08:46, Jonathan Hull <jh...@gbis.com> wrote: > > 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 <pana...@gmail.com> 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 >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On Feb 19, 2017, at 7:29 PM, David Waite via swift-evolution >>>> <swift-evolution@swift.org> 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 >>> 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
