Very much agree with essentially all of that. Personally, I'd also want to explore whether any submodule scope could just subsume fileprivate (i.e., files not otherwise in a submodule behave as though they are their own submodule for access control purposes) rather than occupy another slot between it and internal, but that's a discussion we can postpone until a submodule proposal takes shape.
On Sat, Oct 8, 2016 at 17:27 Matthew Johnson <matt...@anandabits.com> wrote: > > > Sent from my iPad > > On Oct 8, 2016, at 3:24 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Sat, Oct 8, 2016 at 2:15 PM, Matthew Johnson <matt...@anandabits.com> > wrote: > > > On Oct 8, 2016, at 2:01 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote: > > On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution < > swift-evolution@swift.org> wrote: > > > On 8 Oct 2016, at 16:47, Braeden Profile <jhaezhy...@gmail.com> wrote: > > > On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution < > swift-evolution@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? > > > There are rather significant optimization barriers at module boundaries > right now. These do not exist for the standard library due to its tight > relationship with the compiler, but for the moment it is a non-trivial > concern for 3rd party code that is performance sensitive. This is > effectively a language pressure in the direction of larger modules, at > least for some domains. (Hopefully this pressure will eventually be > alleviated - there has been at least some talk in that direction) > > > Great point. IMO, it'd be important to identify how much of the desire for > additional varieties of access modifiers represent workarounds to compiler > limitations, because we'd be better off making optimization across module > boundaries work better if that's the root of the issue. Certainly, also, > submodules are a discussion that, having made a brief appearance at the end > of Swift 3 evolution, would be ripe for Swift 4 phase 2. > > As for this topic about additional access modifiers, I'd like to > understand what current use cases motivate them that arise because the > current syntax is insufficiently expressive, rather than compiler > shortcomings or the lack of other features that are on the horizon. The > latter sorts of motivation, IMO, would be more definitively addressed by > tackling the root problem; adding additional syntax in order to work around > compiler limitations seems as best inelegant. > > > I agree completely. We definitely don't want to add features motivated > only by current limitations. > > IMO there is plenty of motivation for submodules from a number of > different angles. If we do add them I think allowing an access control > distinction between submodule and whole module makes a lot of sense. That > isn't sufficient motivation on its own of course, but is still very > relevant to any discussion of any access level between fileprivate and > internal. I also believe it is very likely to be the best and most natural > solution. > > That said, it's always good to keep pushing for better concrete examples > and use cases. > > As for the cross-module performance issue, I very much hope to see that > solved independent of any new features (aside from perhaps some annotations > that help the optimizer and give it more room to work by restricting our > future options for change). > > > > > 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@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 > > > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution