<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Multiple ways for multiple needs. The same way you can support both delegation as well as blocks based callbacks.<br><br>Sent from my iPhone</div><div><br>On 29 May 2016, at 13:23, Leonardo Pessoa via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div><div style="font-family: Calibri,sans-serif; font-size: 11pt;">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.<br><br>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.<br><br>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.<br></div></div><div dir="ltr"><hr><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">From: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">Charlie Monroe via swift-evolution</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Sent: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">29/05/2016 08:29 AM</span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">To: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:brent@architechies.com">Brent Royal-Gordon</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Cc: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;"><a href="mailto:swift-evolution@swift.org">swift-evolution</a></span><br><span style="font-family: Calibri,sans-serif; font-size: 11pt; font-weight: bold;">Subject: </span><span style="font-family: Calibri,sans-serif; font-size: 11pt;">Re: [swift-evolution] [Proposal] Protected Access Level</span><br><br></div><br>> My answer is this: There is nothing magical about being a subclass that ought to grant access to those methods.<br><br>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: <br><br>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.<br><br>> 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.<br><br>That's what "friend" classes are for in C++, similar concept would be applied here.<br><br>> 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<br><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>