[swift-evolution] Type-based ‘private’ access within a file

[Vladimir.S]

On 06.04.2017 20:41, Jordan Rose via swift-evolution wrote:
> Hi, -evolution. I’ve said this before, but *I think this new proposal is a
> terrible idea*. It privileges types in a way that is damaging to the language.
>
> [There isn't really anything new in my discussion below; everyone on-thread
> is smart enough to have brought up these points already. But I wanted to go
> on record about it, at least.]

Thank you for sharing your opinion regarding this subject.
Do I understand correctly, that *you* propose to just revert access levels 
and modifiers to Swift2 stage? (i.e. to drop current 'scoped-private' and 
rename 'fileprivate'->'private')
Or do you support to leave current 'scoped-private' under another name?

Vladimir.

>
> The claimed problem with the current version of 'private' (let's call it
> "scoped-private") is that it encourages developers to make monolithic type
> declarations instead of using extensions. With the proposed new
> interpretation (let's call it "extension-file-private"), there's a similar
> problem: developers are encouraged to put everything in the original type
> even when it may be more appropriate to
>
> 1. Extend another type (e.g. converting initializers)
> 2. Use a helper type (a nested type always inherits the generic parameters
> of its enclosing type)
> 3. Break a single protocol or class out into a hierarchy (subtyping should
> be used /sparingly/ but not /never)/
>
> Of course, one can always add an extension to access the
> extension-file-private members from outside the type, but that just
> underscores how little expressive power this level would actually have.
> These are cases where 'fileprivate' is the /correct/ tool for the job.
>
> I liked the original three levels of access (not a surprise to anyone,
> since I was a primary designer), and one reason for that is that the access
> levels are /completely indepedent/ of the declarations you're writing. You
> can organize your code in whatever way makes the most sense, and the access
> levels will then help you enforce that organization. I do think SE-0025
> should not have been accepted, that it does not add enough benefit given
> the increase to complexity, but even scoped-private can be used as an
> organizational feature that prevents you from making mistakes, and it still
> offers a simple answer to where a declaration can be used.
>
> The proposed extension-file-private exposes a declaration to an arbitrary
> subset of the file it's in, because being within an extension of a type or
> not is arbitrary with regards to code organization. Extensions /are/ used
> organizationally, but there's now no way to distinguish whether the private
> members of /this/ extension are related to the private members
> of /that/ extension, or whether they were supposed to be independent.
>
> Everyone is acting like "fileprivate" is a problem. While we may not like
> the name, /it's still the right tool for the job./ What else do you have in
> the file that you're trying to protect?
>
> Let's not add a mishmash of a feature just because it's "practical" for
> some uses.
>
> Thanks for hearing me out,
> Jordan
>
> P.S. I have a /lot/ to say on the idea of "submodules", and the dozen
> different things people want from them. I'll try to write that up later, so
> that people can refer to it if/when we ever get around to discussing such
> features. But it's not relevant right now.
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>