What about private, fileonly, moduleonly, public ? *___________________________________*
*James⎥Future Prime Minister* *[email protected] <[email protected]>⎥supmenow.com <http://supmenow.com>* *Sup* *Runway East * *10 Finsbury Square* *London* * EC2A 1AF * On Thu, Mar 31, 2016 at 1:24 PM, Pierre Monod-Broca via swift-evolution < [email protected]> wrote: > 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]> 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]> wrote: >> > >> > Looks good to me. >> > >> > -Thorsten >> > >> >> Am 31.03.2016 um 06:22 schrieb Chris Lattner via swift-evolution < >> [email protected]>: >> >> >> >>> On Mar 23, 2016, at 10:13 PM, Chris Lattner <[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] >> >> 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 > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
