[swift-evolution] SE-0025: Scoped Access Level, next steps

[Sean Heber]

I know this is kind of winding down, and there seems to be a kind of begrudging acceptance of “fileprivate” emerging (perhaps due to fatigue), but I still really don’t like it so I’m going to toss out my current favorite configuration and try to stop caring and defer to the core team to make an executive decision so we can all move on with our lives. :P

public - unchanged, visible “everywhere"
external - visible outside of the file (module, the default)
internal - visible only within the file
private - visible only within the scope

I really like the existing private and I use it a lot to build collections of small classes and structs that work together rather than a large class/struct that tries to “be everything”. In those scenarios, traditional OO private would be too restrictive and even a “protected” access type wouldn’t work because I’m trying to avoid building inheritance hierarchies. I really need something like “friend” (ugly) or the, imo, much more elegant file-scoped access and if that one is renamed “fileprivate” I’ll be really sad seeing such an ugly label all over the place. I’d go so far as to suggest that an ugly name for this access level would actively discourage its use and while some might have that as a goal, to me that would encourage the creation of larger “do everything” classes instead of clusters of smaller classes and structs and protocols.

l8r
Sean

> On Apr 1, 2016, at 7:17 AM, Joanna Carter via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> I’ve seen a number of concerns on this list about moduleprivate, and how it penalizes folks who want to explicitly write their access control.  I’ve come to think that there is yes-another possible path forward here (which I haven’t seen mentioned so far):
>> 
>> public
>> internal
>> fileprivate
>> private
>> 
>> The advantages, as I see them are:
>> 1) We keep public and private meaning the “right” and “obvious” things.
>> 2) The declmodifiers “read” correctly.
>> 3) Compared to Swift 2, there is almost no change.  The only thing that changes is that some uses of Swift 2 “private” will be migrated to “fileprivate”, which makes the intent of the code much more clear.
>> 4) fileprivate is the unusual and not-really-precedented-in-other-languages modifier, and it would still be “googable”.
>> 5) The addresses the “excessively long” declmodifier problem that several people are concerned with.
>> 6) Support for named submodules could be “dropped in” by parameterizing “internal”.
>> 
>> Thoughts?
> 
> +1
> 
> Following on from my experience with Delphi adding "strict private" for "OO private" members of classes, I would totally agree with your proposition.
> 
> Having to use Delphi's "strict private" never really felt right to those of us who were brought up on the OO concept of private, and having "private" mean file scope simply encouraged very bad, large, files with lots of classes; especially for those who were new to programming.
> 
> This proposal means that folks coming from other OO languages will instantly understand "private"; "fileprivate" does what it says on the tin.
> 
> To my mind, the only extra scope that might be useful is the OO concept of "protected" on a class, but I would like to see a discussion purely centred on the effect of more protocols and less class inheritance, with its attendant impact on whether protected could also suit extending (otherwise private) scope to extensions.
> 
> In recent experiments of adapting the GOF Design Patterns to Swift, I have found using protocols and extensions to greatly reduce the need for class inheritance, if not removing the need for classes at all in favour of structs.
> 
> Joanna
> 
> --
> Joanna Carter
> Carter Consulting
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution