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@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@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
