I like : - public - modulewide or moduleprivate or internal - filewide or fileprivate - private
I really dislike interfile because the word exists and means something else I dislike intermodule, inmodule and infile because I don't find them intuitive at all. I prefer the -wide flavors because they're shorter than the -private flavors, and because -wide is an existing suffix in english. Internal has the advantage of no modification but if we want to change it, now is the time. > Le 31 mars 2016 à 11:10, Ross O'Brien via swift-evolution > <[email protected]> a écrit : > > > public > > internal > > interfile > > private > > Linguistically, I really like this direction. 'interfile' is one word, it > reads as an adjective, it can be used in conversation (this has interfile > visibility), and it's clear about where its visibility ends. > > It just doesn't mean what you think it means. > > 'inter' means 'between'. See: 'intergalactic', 'interstellar', > 'international', 'internet'. So 'interfile' would have to mean 'visible > between files' - i.e. an interfile symbol in one file is visible in another > file. The prefix you're looking for, meaning 'internal', is 'intra' (see: > 'intravenous', 'intranet'). > > So the scale would become: > > public / intermodule > internal / intramodule / interfile > intrafile > private > > > On Thu, Mar 31, 2016 at 6:04 AM, Paul Ossenbruggen via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > public > internal > interfile > private > > still googleable and very clear its scope and meaning, nice latin root. > Doesn’t overload “private”, slightly shorter. > > > > On Mar 30, 2016, at 9:46 PM, Thorsten Seitz via swift-evolution > > <[email protected] <mailto:[email protected]>> wrote: > > > > Looks good to me. > > > > -Thorsten > > > >> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution > >> <[email protected] <mailto:[email protected]>>: > >> > >>> On Mar 23, 2016, at 10:13 PM, Chris Lattner <[email protected] > >>> <mailto:[email protected]>> wrote: > >>> How about we continue this trend, and follow other existing Swift > >>> keywords that merge two lowercase words (associatedtype, typealias, etc), > >>> and use: > >>> > >>> public > >>> moduleprivate > >>> 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) The unusual ones (moduleprivate and fileprivate) don’t use the awkward > >>> parenthesized keyword approach. > >>> 4) The unusual ones would be “googable”. > >>> 5) Support for named submodules could be “dropped in” by putting the > >>> submodule name/path in parens: private(foo.bar.baz) or > >>> moduleprivate(foo.bar). Putting an identifier in the parens is much more > >>> natural than putting keywords in parens. > >> > >> 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? > >> > >> -Chris > >> _______________________________________________ > >> swift-evolution mailing list > >> [email protected] <mailto:[email protected]> > >> https://lists.swift.org/mailman/listinfo/swift-evolution > >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > > swift-evolution mailing list > > [email protected] <mailto:[email protected]> > > https://lists.swift.org/mailman/listinfo/swift-evolution > > <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <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
