You know the default access is was is used for this, right? And in this case I don't think they meant it for external subclasses to be able to access this change.
I think this is how Swift was meant to work allowing only classes in a certain module to access such "private shared" parts and using delegates for these extensions. I'm not saying I'm against protecteds but it's hard to get used to use another way of programming when most other languages we previously learned had a different philosophy. Sure everyone has the right to discuss they like this new philosophy or not but we should also question ourselves if this is the right way to go because it will completely change the philosophy of the language. Should this pass, we may start facing the core library using the delegate philosophy (I don't believe Apple will change it) and third-party modern frameworks using old school subclassing with protected parts. That's two ways of doing the same thing and I don't think this will be much good to anyone. -----Original Message----- From: "Charlie Monroe via swift-evolution" <[email protected]> Sent: 29/05/2016 08:29 AM To: "Brent Royal-Gordon" <[email protected]> Cc: "swift-evolution" <[email protected]> Subject: Re: [swift-evolution] [Proposal] Protected Access Level > My answer is this: There is nothing magical about being a subclass that ought > to grant access to those methods. There is - it's a family member that you let use your summer house. Without the metaphor, here is an example for this being useful: URLConnection subclass may want to update the URL in case of a redirect, but you don't really want to expose the setter for the URL to public. > For instance, if your subclass grows very complicated and you extract a > helper object, it's perfectly reasonable for that helper object to want to > access the "subclass-only" API. That's what "friend" classes are for in C++, similar concept would be applied here. > Contrarily, simple subclasses might not need that API, and exposing it to > them would be an unnecessary risk. And there are things which you don't > subclass at all which could benefit from being hidden away—think of the > Objective-C runtime, which has some parts which every app needs (like the > definition of `BOOL`) and othe _______________________________________________ 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
