I also agree with everything Jordan said! -Thorsten
> Am 25.03.2016 um 17:27 schrieb David Owens II via swift-evolution > <swift-evolution@swift.org>: > >>> On Mar 25, 2016, at 9:15 AM, Jordan Rose via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> >>> >>>> On Mar 24, 2016, at 16:20 , Erica Sadun via swift-evolution >>>> <swift-evolution@swift.org> wrote: >>>> >>>> >>>>> On Mar 24, 2016, at 5:13 PM, Brent Royal-Gordon <br...@architechies.com> >>>>> 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 think this is a very important observation. Being able to talk about these > levers is very important, especially in the context of teaching new people > about the various levels of access control. > >> 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.) > > I agree 100% with this. > >> >> Jordan >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
