> On 08 Oct 2016, at 19:17, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > > > 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.
fileextension MyClass.swift > >> >> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
