[swift-evolution] private & fileprivate

[Xiaodi Wu]

On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <
swift-evolution at swift.org> wrote:

>
> On 8 Oct 2016, at 16:47, Braeden Profile <jhaezhyr12 at gmail.com> wrote:
>
>
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I was thinking that the domains themselves could be associated with a
> domain, so you could create alternate domains which are also
> publicly-visible, but distinct from the default, “public” domain.
>
> For example, if you have a bunch of methods which should be visible to
> subclasses, but you don’t want them to clutter your regular interface.
> Perhaps they have names which are confusingly-similar to the public API. I
> believe that is what “protected” is typically used for.
>
>
> Yes, but “protected" was specifically put down by the core team, seeing
> that any code from outside the library should see the class as one
> well-designed whole, not something with complicated, visible implementation
> details.  If your class-internal methods are confusing (and aren’t
> necessary for normal use), they shouldn’t be made public in any way.
> Subclasses would too easily confuse the distinction between your
> implementation methods and your public ones.
>
> For what it’s worth, I was only confused by “private” and “fileprivate”
> for a minute or two until I looked up the actual proposal.  I haven’t had
> trouble with it, and it does actually provide more flexibility for code
> access at the file level than we had before.  Even if the syntax is clunky.
>
>
> I’m not saying that (file)private is confusing - it’s very clear about
> what it does. But it is limiting; anything that wants access to those
> semi-private details needs to live in the same file. That’s clearly not
> scalable. Enormous files many thousands of lines long are easy for the
> compiler to digest, but less easy for humans to understand and navigate. In
> fact, I believe this whole “file-based” access control originally came out
> of the compiler’s implementation details.
>

I'm interested in more information about this. What sorts of code have you
been writing where a file would have to be thousands of lines long in order
to accommodate `fileprivate`? Many entire modules are only thousands of
lines long--is there a reason this code couldn't be refactored into a
module of its own? As mentioned by Matthew, isn't this calling for some
notion of submodules?

What it would basically come down to is that the interface of the object
> would be separated in to blocks based on your access privileges. When
> viewing the interface, it wouldn’t look much different to an extension:
>
> *access(public)* class TabController {
>    var tabs : [Tab] { get }
>    func closeTab(at: Int)
> }
>
> *access(TabBarStuff)* extension TabController {
>     func close(tab: Tab)
> }
>
> I definitely want something between internal and fileprivate, at least. I
> don’t see any reason at all why objects shouldn’t be allowed to present
> optional “slices” of their interface to appropriate clients. In fact, that
> is what access control is all about. I just want to generalise it to allow
> for user-defined visibility scopes (as well as the default ones for public,
> module, file and scope). That leads to the question of what visibility
> those user-defined scopes would have; and if you leave them entirely open
> to adopt any scope (except themselves), then you end up with the ability to
> slice your API for different use-cases. Or we could be boring and limit
> them to the module they are defined in.
>
> The whole reason I’m bringing this up is because I don’t like the “file”
> part of fileprivate. How I split my files up is a readability decision.
>
> Karl
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161008/55e6435a/attachment.html>