A battle shout of "you will need language lawyers to decide all we are building to avoid protected" ;)?
Sent from my iPhone > On 13 Feb 2017, at 23:38, Xiaodi Wu via swift-evolution > <[email protected]> wrote: > > The beauty of Swift 2's access modifiers was that they were based around > files and modules, explicitly rejecting types and scopes as units for > determining visibility. It seems at base there's a group of people who reject > that decision altogether. Hence, new `private`, proposals around `protected`, > `friend`, `hidden`, `extensible`, etc. > > The point of the other thread was that a sizable proportion of people are > finding the old system to be elegant and a suitable basis for future > enhancements such as submodules. Here, there's another proportion of people > who want to dismantle the old design completely. This was pitched already > during the Swift 3 evolution process, repeatedly. > > At some point, we've got to stop relitigating this design. It's untenable to > have something as foundational as access control change with every version of > Swift. > > My two cents are that supporting all the shades of private is completely a > non-goal. I've yet to be convinced that more access modifiers will improve > anyone's code sufficiently to justify any more turmoil in the language. The > Swift 2 way took a very pragmatic approach. When can I access this member? If > private: when I have the source code already open; if internal: when I have > the source code available to open; if public: whenever. It takes the > opinionated (but IMO correct) view that it's not particularly useful for the > compiler to hide something from you that you can plainly see and touch. > > >> On Mon, Feb 13, 2017 at 5:04 PM, Joanna Carter via swift-evolution >> <[email protected]> wrote: >> What still strikes me as odd is that we now seem to have a plethora of >> visibilities, some of which do not provide for a given context, some of >> which seem to be looking for a context to justify their existence. >> >> Whatever it is called, I find the idea of a file scope visibility somewhat >> bizarre and at odds with the principle of standard OO class encapsulation. >> >> The two main reasons I can see for the perceived need for fileprivate are : >> >> 1. being able to separate out "sections" of a class into various extensions >> >> 2. giving global junkies the ability to write all their code in one unit >> >> Surely, there are members of a type that the writer wants to remain private, >> even if an extension were declared in the same file. Fine, we have private >> for that and, even if the writer declares members to be fileprivate, there >> is no way that any extension declared outside of the file can see those >> members. >> >> Now, I have a problem with that. If I want to access non-public members when >> I extend a type, either I declare those extensions in the same unit and >> declare those members as fileprivate, or if I want to declare those >> extensions in another file, I have to move up to the next suitable scope, >> which is internal. >> >> But internal is too "open" because it allows, not only my chosen extensions >> to see those members but, also, any other code in the entire module. >> >> Having made use of the "friend" concept in C++, this "all or next to >> nothing" approach to visibility seems to leave me in much the same place as >> Objective-C, where I could only have private or public, unless I did some >> tricky stuff with class extensions, something which really didn't look that >> pretty. >> >> There are some parts of a type that I would want to remain really, really >> private to the type, not even visible to an extension. >> >> There are other parts of a type that I would want to be private to that type >> but also visible in, but only in, extensions explicitly written against that >> type. >> >> Which is why I am suggesting the "extensible" scope : private to the >> declaring type but also and only visible within any extension to that type. >> >> Here follows a highly contrived example : >> >> // Person.swift >> public struct Person >> { >> public var name: String >> >> public extensible(set) var dateOfBirth: Date >> >> public var age: Int >> { >> // return calculated age as of today >> } >> >> init(name: String, dateOfBirth: Date) >> { >> self.name = name >> >> self.dateOfBirth = dateOfBirth // accessible as if it were private >> } >> >> // Registrar.swift >> extension Person >> { >> func correct(dateOfBirth: Date) >> { >> self.dateOfBirth = … >> } >> } >> >> // Test.swift >> { >> let person = Person() >> >> person.dateOfBirth = … // compilation error, not visible >> } >> >> IMHO, this then removes one use case for fileprivate in that it allows >> privileged visibility to private members of a type in extensions, both in >> the same file and in any other file. But, it also ensures that not other >> code is allowed access, whether that be in non-extension code in the same >> file or other non-extension code anywhere else. >> >> As for case 2. for fileprivate, if a developer wants to put all sorts of >> globals and other code in one file, then I doubt if they are even going to >> bother to use fileprivate, especially when they get internal visibility with >> less typing ;) >> >> Now, if someone could help me prepare this as a proposal… >> >> -- >> Joanna Carter >> Carter Consulting >> >> _______________________________________________ >> 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
