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

Fri Apr 1 12:25:30 CDT 2016

In terms of alternatives to fileprivate, I just want to chime in to say
that "filewide" seems to be a term that people seem to reach for in
describing this scope, based on a quick Google search.

It's readable, IMO, and definitely an adjective, it breaks no new ground in
terms of coining a new term, and it is adequately descriptive. Plus, it
avoids the issue of having two things named fileprivate and [bona fide]
private.

For those reasons, it's got my vote over "file", "fileprivate", "infile",
"intrafile", etc.

On Fri, Apr 1, 2016 at 11:11 AM Paul Ossenbruggen via swift-evolution <
swift-evolution at swift.org> wrote:

> How about:
>
> notprivateatall
> notveryprivate
> mostlyprivate
> stayout!!!private
>
> Sorry. April fools.. :-)
>
> On Apr 1, 2016, at 8:00 AM, Ross O'Brien via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> "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
>> >
>>
>>
> _______________________________________________
> 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/2c8f3022/attachment.html>