Sent from my iPad
> On Oct 8, 2016, at 12:02 PM, Karl via swift-evolution > <[email protected]> wrote: > > >>> On 8 Oct 2016, at 16:47, Braeden Profile <[email protected]> wrote: >>> >>> >>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution >>> <[email protected]> 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. > > 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. It seems to me that some kind of submodule facility is probably the best way to accomplish what you describe here. > > Karl > _______________________________________________ > 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
