[swift-evolution] private & fileprivate

[Xiaodi Wu]

I don't find this example persuasive, because:

1125 LOC is on the long side for a single file, but not by any means
"thousands" of LOC.

In any case, having hacked on corelibs-foundation myself, my sense is that
its files are organized in such a way that NSDecimal would be expected to
be implemented in a single file regardless of length.

If Swift had submodules, there's no reason to say that Foundation wouldn't
make use of them to organize its types.

Even if you wished to share implementation details between, say, a
hypothetically split up NSDecimal and Decimal, fileprivate members of
NSDecimal could simply be internal instead, as is done elsewhere in
corelibs-foundation. Note by comparison that, for implementation reasons,
stdlib doesn't use fileprivate scope and all implementation details are
internal or even public and underscored. A compelling argument for more
fine-grained controls here would demonstrate how internal scope in stdlib
or corelibs-foundation actually led to a bug that could have been
prevented--I don't think any such bug exists.
On Mon, Oct 10, 2016 at 04:30 Alex Blewitt <alblue at apple.com> wrote:

>
> 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> wrote:
>
>
> On 8 Oct 2016, at 16:47, Braeden Profile <jhaezhyr12 at gmail.com> wrote:
>
>
> On Oct 8, 2016, at 6:58 AM, Karl via swift-evolution <
> 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.
>
>
> https://github.com/alblue/swift-corelibs-foundation/blob/nsdecimal/Foundation/NSDecimal.swift
>
> 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.
>
> Alex
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161010/648e9ae5/attachment.html>