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@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 <s...@fifthace.com > <mailto:s...@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+sw...@gmail.com > > <mailto:narrativium%2bsw...@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@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@swift.org <mailto:swift-evolution@swift.org> > > > https://lists.swift.org/mailman/listinfo/swift-evolution > > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > _______________________________________________ > > swift-evolution mailing list > > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
