[swift-evolution] [Proposal] Protected Access Level

[Goffredo Marocchi]

Multiple ways for multiple needs. The same way you can support both delegation as well as blocks based callbacks.

Sent from my iPhone

> On 29 May 2016, at 13:23, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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.
> From: Charlie Monroe via swift-evolution
> Sent: ‎29/‎05/‎2016 08:29 AM
> To: Brent Royal-Gordon
> Cc: swift-evolution
> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160529/f1b17c60/attachment.html>