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

[Ross O'Brien]

A new type is implicitly internal to a module. Implicitly specifying it as
'external' is just plain confusing.

On Fri, Apr 1, 2016 at 3:01 PM, Sean Heber via swift-evolution <
swift-evolution at swift.org> wrote:

> 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
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160401/74261c5b/attachment.html>