I still think that "local" expresses the concept exactly, as it restricts visibility to the local scope, doesn't it?
-Thorsten > Am 25.03.2016 um 17:46 schrieb Ross O'Brien via swift-evolution > <[email protected]>: > > Well, several prominent voices seem to think that 'private' is "intuitively > obvious" when it refers to declaration-level scope, so I didn't argue that > point. I still happen to disagree; I would add 'privatetodeclaration' to > 'privatetomodule' and 'privatetofile', which would solve that conversational > point: "These properties are private to the declaration". > > Alternatively: 'fileaccessible', 'moduleaccessible', 'declarationaccessible'? > (Does that confuse code accessibility with such things as UIAccessibility?) > > That doesn't answer your awkward-to-read-in-code problem. I don't have a > solution to that. > > To re-specify the problem, again (perhaps more for my benefit while writing > as yours while reading): the terms we choose have to suggest accessibility, > but a subjective spectrum of adjectives does not give us clarity. The idea of > building into these symbols references to exactly where the scope ends > appears to be popular. There aren't any existing one-word terms which express > these concepts so we're coining new words out of two (or more) existing > words. Which combination of words is least awkward to read, or most intuitive > to type, is still going to be subjective. > > >> On Fri, Mar 25, 2016 at 4:29 PM, Jordan Rose <[email protected]> wrote: >> It doesn't solve the problem for me. "These properties are private." "To >> what?" "Just private" / "To the scope". >> >> They're also still awkward to read in code. I know we have lots of decl >> modifiers, but I've convinced myself we're not in Java's "public static void >> main" soup situation yet. >> >> Jordan >> >> >>> On Mar 25, 2016, at 9:27 , Ross O'Brien <[email protected]> wrote: >>> >>> Well... how about we reverse the terms: call them 'privatetomodule' and >>> 'privatetofile'. >>> >>> This is 'private(module)' and 'private(file)' but fitting the all >>> lower-case style. It puts 'private' first (and when you use the keyword, >>> 'private' is the bit you want to start with more than 'module' or 'file'). >>> It's easier to use in conversation ("these properties are private to the >>> file"). >>> Disadvantage: it adds 'to', so the words are even longer (but no longer >>> than the parenthesised form would've taken). >>> >>> 'privatetofile extension Foo : BarConvertible { }' >>> >>>> On Fri, Mar 25, 2016 at 4:15 PM, Jordan Rose via swift-evolution >>>> <[email protected]> wrote: >>>> >>>>>> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> >>>>>>> On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon >>>>>>> <[email protected]> wrote: >>>>>>> >>>>>>> I think it does. `module` could mean many things related to how Swift >>>>>>> creates and consumes modules. >>>>>>> `moduleprivate` combines something about access levels (public/private) >>>>>>> and scope (module), is easy to >>>>>>> Google, offers few "wrong" interpretations. By using a longer keyword, >>>>>>> it is less flexible in meaning and >>>>>>> more fixed in purpose. >>>>>> >>>>>> Sure, but is that worth 7 to 9 extra characters at every single use site >>>>>> for something that's actually pretty common? Is it worth the muddled >>>>>> mess of an all-lowercase keyword with no obvious break, or the >>>>>> attention-grabbing of a capital letter or an underscore? >>>>>> >>>>>> `module` and `file` are not going to be obscure corners of the language. >>>>>> Most people will probably learn about them at the same time they learn >>>>>> about `public` and `private`. >>>>>> >>>>>> (Actually, if `module` continues to be the default, you probably won't >>>>>> see it *that* often. You *will* see `file`, but that's the one that >>>>>> can't be as easily confused with a declaration.) >>>>>> >>>>>> Obviousness for new users is great, but you can take it too far. We call >>>>>> the type `Int32`, not >>>>>> `SignedIntegerBetweenNegative2ToThe31stPowerAnd2ToThe31stPowerMinus1`—and >>>>>> if we did, it's not clear the longer name would really be more obvious, >>>>>> because it would be such a pain to read. >>>>> >>>>> >>>>> `moduleprivate` is the default value. I doubt it will get used much if >>>>> at all. I don't think `fileprivate` will get used much either >>>>> but in such cases, I think those seven extra letters are essential and >>>>> documenting. >>>>> >>>>> The two remaining public and private access levels are simple and >>>>> intuitively obvious. >>>> >>>> I'm going to say that I remain unhappy with these new names. I don't >>>> believe that these won't get used, and I don't want them to feel awkward, >>>> discouraged, or penalized when they do. The standard library, for example, >>>> has in its style guide that all access control should be explicit, which >>>> is a reasonable style to enforce. I also have a small concern that they >>>> won't be easy to talk about: "this method is private" "wait, file-private >>>> or module-private?" "neither, just private-private". >>>> >>>> I realize these are all vague concerns, and I don't have something more >>>> concrete—or a better alternative. "modulescoped" and "filescoped" would be >>>> very literally accurate but (a) would force people to learn what "scoped" >>>> means unnecessarily, and (b) aren't less awkward. >>>> >>>> I agree with the concerns that just saying "file var foo" makes it sound >>>> like there's one copy of the variable shared in the entire file, even when >>>> applied to an instance property. I think there's a lot of value is making >>>> the access control terms adjectives. >>>> >>>> I honestly still think "public, internal, private, local" is a better >>>> taxonomy.. It's true that "internal" and "private" aren't automatically >>>> ordered relative to each other (and maybe not even "local"), but they're >>>> all adjectives (unlike "module" and "file"), and they're not awkward to >>>> read or to use in conversation. But both the core team and the list >>>> disagree, mainly because (a) it aligns 'private' more closely with other >>>> languages, and (b) if you're not thinking about it, more restrictive is >>>> better than less. (Both of which I agree are good ideas.) >>>> >>>> Jordan >>>> >>>> _______________________________________________ >>>> 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
