It might be worth being more specific with your comparison between the "lock and key" access control I described and the other techniques described in this thread. Given that the designers of Swift were familiar with protected access level from other languages and deliberately chose to exclude it, it seems likely that you'll need to give some detailed pros and cons to get a protected access level accepted I think.
I don't personally have an opinion on whether protected is a compelling addition to the Swift language. It's in some of the languages that I use and not others. I use it extensively where available, but it's not a compelling enough feature on its own to make me choose one language over another. I just wanted to make sure that people were aware of some other techniques available for implementation hiding that are available in the language today. (There are many more than just the one I presented if you're willing to take a small runtime cost). -- Callionica On Sun, May 29, 2016 at 10:59 PM, Rod Brown <[email protected]> wrote: > I have to agree with Charlie Monroe that while this is doable, it's clear > this is a workaround to a problem, not a viable long term language solution. > > - Rod > > > > Sent from my iPhone > On 30 May 2016, at 2:49 PM, Callionica (Swift) < > [email protected]> wrote: > > I've written up how to provide protected access control for Swift code > today here: > > http://www.callionica.com/developer/#swift-protected > > No compiler changes necessary for this technique and it distinguishes > between methods that can only be overridden and methods that can be both > called and overridden. > > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
