[swift-evolution] private & fileprivate
alblue at apple.com
Mon Oct 10 04:30:26 CDT 2016
> On 8 Oct 2016, at 20:01, Xiaodi Wu via swift-evolution <swift-evolution at swift.org> wrote:
> On Sat, Oct 8, 2016 at 12:02 PM, Karl via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> On 8 Oct 2016, at 16:47, Braeden Profile <jhaezhyr12 at gmail.com <mailto:jhaezhyr12 at gmail.com>> wrote:
>>> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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?
I'm implementing NSDecimal in Swift and it uses fileprivate to wrap up scope for internal implementation details. The implementation that I've got on my GitHub account is currently at 885 lines; but I'm still working on other parts and my currently checked out version has 1125 lines of code, in a single file.
Submodules aren't the right answer here, because Foundation as a while is a module that won't be split apart. And for performance reasons, you want the internal functions (defined fileprivate) to be considered as eligible for optimisation by the compiler in the absence of (say) whole module optimisation.
Right now, the only way to do that is to have the fiileprivate implementations in the same file as the rest of the implementation.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution