Did take a while to get it into Xcode - But easily navigable with the symbol navigator. No speed issues, too.
I may not understand a problem here? Why is this not easy to use for you?
Because it's not just about knowing what the methods are called. If you're trying to fix a bug, or add functionality, you have to understand how they work and how they interact with each other. Breaking it down into smaller parts makes that a thousand times easier to do.
From what I see here this would be easily possible. I haven't found much tight coupling in the types I looked at so they could be split into multiple files.
Splitting into multiple files is kind of what we're asking for.
Currently if you do it, you often have to expose the internal state to the entire module...
But splitting is possible already as long as the parts are not tightly coupled. Does is really often happen that such big files are all over tightly coupled? After all property values should be access even in method by the accessors and not a direct access.
So do I simply see some part of the problem not before all that lines? 
Yes. Yes, it does.
Go back to my custom view example. Does it really seem plausible to you that the code that generates the content, the code that draws that content on the screen, and the ten kajillion protocols that manipulate that content in various ways aren't going to need to access internal state?
Yes, or more correctly only though accessors. I appear to use a very different coding style from you.
Accessors aren't the issue here. The issue is exposing internal state to outside code.
Accessors that are visible to the entire module expose internal state to the entire module. Accessors that aren't visible to the entire module, currently, aren't visible outside your one gargantuan file.
1 Like
Can you elaborate why your coding style is superior to others and why you think Swift should only prioritize such coding style only? As mentioned by others multiple times Swift should be style-agnostic. This raises a question why should a sub-system in Swift not follow that state of art?
1 Like
An accessor does hide the internal representation and provides an api for usage. Where is the problem when this api is internal? After all the internal representation is never endangered by the usage of this api. 
Because often times the internal representation doesn't need to be exposed to the user at all, whether through an API or otherwise. It is not something that the user needs to be concerned with. It is only relevant to the various components of the, for example, view class, and exposing it to outsiders is just polluting the interface.
I din't say it was superiour. I currently try to understand the problem.
But my methology to only use accessor and provide a api to the internal representation is state of the art since Small-talk's days. It's basic oop design
Isn't that already made sure by only exporting public from any module?
I think what Charles is trying to say is that on Apple platforms by today open and public does not exist, except for modules and frameforks, all App targets are suffering by this problem where internal becomes the top most access modifier and private takes over it's role. private is meant to be, well private and no other types should be able to touch it no matter of the public or internal API, hence the title of this thread.
1 Like
Exactly. In an application target, internal essentially is public. And without something in between, you can't follow that basic oop design you describe, unless you stuff everything into massive, cumbersome behemoth source files.
It has nothing to do with whether your classes use accessors or not; that's a non-sequitur, like responding to someone taking a position on whether red or white wine should be paired with a particular dish, by arguing about the shape of the glass it should be poured in. It's an orthogonal issue.
2 Likes
So we are not talking about library code? Was under the impression access control was only useful for frameworks etc. I have never felt a reason to partition away pure application code from myself or my team. Perhaps that is the thing that hinders me understanding the problem. Hmm.
Guess I need to sleep over this.
It's helpful for library code as well. Because unless you have a separate framework for every single view/class/type, there are going to be parts of your framework that don't need to know about other parts. Take AppKit, for instance. Does NSTableView need to know how the internals of NSSavePanel work? Probably not. Is all of AppKit developed by the same person, who has the public interfaces of all the other AppKit classes memorized so s/he can be sure never to accidentally call internal NSTableView methods that autocomplete brought up when putting a table view inside an NSSavePanel? I'm gonna say no.
2 Likes
Guess I have done to much Python to understand where the problem lies with framework parts having internal access to all the framework's components
Like many others, I really have no intention of weighing in on this topic. However, I am not sure where people are getting this notion that Swift is "style-agnostic" or "non-opinionated."
As Chris Lattner has stated previously: "We intentionally want Swift to have a common 'center of gravity' and be an 'opinionated' language, rather than fall to the 'design by committee' approach that leads to a watered-down design."
The current state of access control reflects Swift's center of gravity after extensive discussion. To the extent that it does promote a certain style of coding, the language deliberately takes a non-neutral position.
7 Likes
Personally, I donāt have this problem. For me, object composition is the answer. If the object needs to be split into multiple files to be readable, itās ... well a mega object. Still, Iām all for removal of āfileprivateā.