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 < [email protected]> 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 < > [email protected]> 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 <[email protected]> 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 <[email protected]> >> 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 < >> [email protected]> 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 < >> [email protected]> 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 >> > > [email protected] >> > > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > [email protected] >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
