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
