> 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 <mailto:swift-evolution@swift.org>> wrote:
>
>> On 8 Oct 2016, at 16:47, Braeden Profile <jhaezhy...@gmail.com
>> <mailto:jhaezhy...@gmail.com>> wrote:
>>
>>>
>>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution
>>> <swift-evolution@swift.org <mailto: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)
>
> 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 <mailto:swift-evolution@swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <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
