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

[Ross O'Brien]

"or within my whole program (external)". That caused a double-take on its
own.

external things are not within, they are outside. 'external' could be a
replacement term for 'public', not for 'internal'.

This may well be a subjective thing, but I don't think in files, I think in
modules because that's been the default for several years now. If I create
a new type I am implicitly making it visible to everywhere within this
module; it is not outside the module so it is not external. I may then
choose to make it less visible, but it does not 'go inside' when I do this.

If you think in files, I cannot say you are wrong, because it is
subjective. But this is why I have been arguing for non-subjective
keywords. I cannot make 'fileprivate' pretty for you but I do know that
when we both read it we both understand what it means. That's why it hasn't
gone away: it satisfies the criterion of clarity.

Find a pretty alternative with the word 'file' baked into it and I'm with
you.

On Fri, Apr 1, 2016 at 3:31 PM, Sean Heber <sean at fifthace.com> wrote:

> A new type is implicitly visible *outside* of the file it is defined in
> and hence it is “external” from that point of view. This arrangement seems
> more “human” to me. Someone just learning isn’t going to know about modules
> or how the compiler is treating things anyway and they would almost never
> run into “external” because it’s the default and there’s no reason to
> specify it most of the time. IMO, this “fits” how I think about source code
> while I’m writing it - where do I want to be able to use this symbol?
> Either hidden away and safe (private), inside this file I’m working with
> (internal), or within my whole program (external).
>
> l8r
> Sean
>
>
> > On Apr 1, 2016, at 9:20 AM, Ross O'Brien <narrativium+swift at gmail.com>
> wrote:
> >
> > 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/06f23ab4/attachment.html>