> On 8 Oct 2016, at 21:01, Xiaodi Wu <[email protected]> wrote:
>
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution
> <[email protected] <mailto:[email protected]>> wrote:
>
>> On 8 Oct 2016, at 16:47, Braeden Profile <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>>>
>>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution
>>> <[email protected] <mailto:[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.
>
> 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?
>
The tab controller was one example:
- final class TabController : UIViewController
- final class TabControllerView : UIView
- final class Tab : UIView
All of these required knowledge of semi-private implementation details of
each-other due to the API I wanted to achieve. I wasn’t interested in factoring
out the interfaces in to protocols because they’re all final classes and only
supposed to be used with each other. For example, Tab.close() called a
fileprivate function in TabController to actually close the tab given an
instance of the underlying TabItem data structure.
In that case, submodules wouldn’t really help. I could technically define the
TabController as a submodule and use “internal”, but that’s also much less than
optimal. I want to expose a handful of functions to a handful of other types
(and not expose those functions anywhere else - e.g. from my module-internal
UIViewControllers which happen to contain a TabController). Also, how would I
expose things from the TabController module to the outer module without making
it fully "public”?
> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
