> On 20 Feb 2017, at 09:39, Goffredo Marocchi via swift-evolution
> <[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) :/.
Why not a best of both worlds?
Everything is open inside the project unless marked private (in the swift 2
sense, i.e. fileprivate)
If a project/module exports a library, the same applies, unless there is a
“library access level control file”.
If a "library access level control file” is present, all external access
defaults to private unless disclosed in the “library access level control file”.
With proper IDE support, creating a "library access level control file” would
require only minimal effort.
This would allow cleaner source code as you do not have to specify every access
level all the time, reduces cognitive load during programming and debugging,
fits nicely in the progressive disclosure strategy, creates a more readable
interface for API users etc etc.
Regards,
Rien
Site: http://balancingrock.nl
Blog: http://swiftrien.blogspot.com
Github: http://github.com/Balancingrock
Project: http://swiftfire.nl
>
> 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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
