[swift-evolution] [Proposal] Protected Access Level
Rod Brown
rodney.brown6 at icloud.com
Sun May 29 18:48:02 CDT 2016
I agree that we should be looking for what makes sense, not just what we’ve seen in other languages. That said, there seems a lot of hate for OOP in general that seems to be clouding people’s vision here.
I think that “protected” as a form of access control is exactly what we want: rights that subclasses should be allowed, but other classes should not. Generally they refer to internal state that only the class itself, or its subclass, has any business either updating or calling.
Lets drop the word “protected” for a second and actually examine the use cases for differing access control in classes. I think the best example of this in different contexts are:
1. Methods and properties that only subclasses must access, but other code has no business updating. An example of this UIGestureRecognizer. State machine type access is something where external items should not access, but internal state may require the rights to update.
2. Methods and properties that should be overridable, but are helper methods and shouldn’t be called by external methods, and perhaps shouldn’t be even called directly. This includes -layoutSubviews on UIView, a multitude of other methods in UIKit, etc. Thus I think Brent had a good point that calling a method might need to have different access rights to overriding it.
I think #1 shows specifically the need for access control for subclasses only, and thus a ‘protected’- style access control level.
I think #2 shows a need to differentiate the access rights of calling a method from access rights to see or override the method.
While we can find workarounds that obfuscate access, these aren’t access controls, they’re convoluted workarounds to avoid correcting our access control rules in the first place.
How do these things bridge into Objective-C?
Protected doesn’t make sense in Objective-C. You cannot subclass a Swift Class in Objective C, so overriding is irrelevant. I suspect the rule should be simple: Anything Protected should not be visible to Objective-C, much like private is hidden currently.
- Rod
> On 30 May 2016, at 8:45 AM, Leonardo Pessoa via swift-evolution <swift-evolution at swift.org> wrote:
>
> Vanderlei, my point in bringing such topics to this discussion is to make everyone here think if we're trying to really enhance the language within its intended purpose or if we're trying to change the language into something else were familiar with from other languages we work/ed with just because we're used to work like that. I just started thinking about this today and just cannot stop now. No intention to start a war here but I think everyone should ask themselves this for every proposed change to the language.
>
> About the topic at-hand, we have to remember Swift is bridged to Objective-C, which has no protected (or abstract). How do you propose these protected members be bridged should the proposal pass?
> From: Vanderlei Martinelli via swift-evolution <mailto:swift-evolution at swift.org>
> Sent: 29/05/2016 06:56 PM
> To: swift-evolution <mailto:swift-evolution at swift.org>
> Subject: Re: [swift-evolution] [Proposal] Protected Access Level
>
> Thank you all for your comments. :-)
>
> Well... My goal is to keep the thing really simple and do not start a new "OOP x POP" (or "something" x "other thing") war.
>
> "Protected" access level is not a new concept at all (except for the Swift language), so I did not propose anything preposterous.
>
> Of course in the Swift of my dreams we also have "abstract" access level modifier, "protected" access level, *real* "private" access level and "file" access level modifier (along with many, many other things, of course). But this proposal is not about this. It is only about include the "protected" access level.
>
> There is, however, something that I need to get off my chest: I really would like to have the freedom to go to the depths with protocols as well with classes. I work in real apps everyday that uses Cocoa frameworks (based on classes) and these apps must be shipped and I like them well written. Maybe am I insane for proposing a better support for classes in Swift? If so, this explains why every time I suggest better support for classes in Swift there is an endless discussion and someone proclaims the death of OOP and is it. OK... Maybe someday we will not have more classes in Swift. Until there: the current language status is the best way to handle OOP in Swift? Or is there a better way? I think there is.
>
>
> Regards,
>
> Vanderlei Martinelli
>
>
>
>
>
>
>
> On Sat, May 28, 2016 at 7:52 PM, Vanderlei Martinelli <vmartinelli at alecrim.com <mailto:vmartinelli at alecrim.com>> wrote:
> Hello.
>
>
> This is the first draft. I'd like to know your opinion about it.
>
> (I know that this subject could have been discussed before. If so, please indicate me the correct thread to follow and interact.)
>
>
> Regards,
>
> Vanderlei Martinelli
>
>
> ---
>
>
> Introduction
> Protected access level will enable entities to be used within the container type and by derived types only.
>
> Motivation
> Today Swift has three access levels (public, internal and private), but lacks a way to describe a member that can be only visible to its type or derived types.
>
> A common case is the UIView from UIKit. Many developers are tempted to make this call:
>
> view.layoutSubviews()
> The documentation says: "You should not call this method directly. If you want to force a layout update, call the setNeedsLayoutmethod instead to do so prior to the next drawing update. If you want to update the layout of your views immediately, call the layoutIfNeeded method."
>
> But yes, you should call this method directly if you are subclassing the view and needs to perform additional layout to its subviews ("subclasses can override this method as needed"):
>
> public override func layoutSubviews() {
> // We are calling the super method directly here.
> super.layoutSubviews()
>
> // Do more adjustments to this view's subviews...
> }
> So, yes, we can call this method directly when subclassing, but the Swift compiler will not prevent you from do this when not subclassing or from any other foreign class. It will not even issue a warning.
>
> In Objective-C problems like this are usually "solved" my adding a kind of "protected" header (.h) that is intended to be included only when the developer is subclassing. In Swift we do not have headers, but we have the new access level model. So, if the declaration of this method was...
>
> protected func layoutSubviews()
> ... no one outside the class or derived classes would be allowed to call this method directly.
>
> Of course, there are other cases in the Cocoa frameworks and there are many other cases when we are developing software in Swift that the protected access level would be very usefull.
>
> Proposed solution
> Create the protected access level.
>
> Detailed design
> Reference Types (classes)
>
> When declarated by a class the protected member will be visible to the class itself and all the derived classes.
>
> // BaseClass.swift
> public class BaseClass {
> public protected(set) var x = 20
> protected let y = 10
>
> protected func doSomething() {
> // ...
> }
> }
>
> // DerivedClass.swift
> public class DerivedClass: BaseClass {
> protected override doSomething() {
> self.x = 10 * self.y
> }
> }
> If the member is declared as final then it will be visible but not can be overrided by the derived classes. Just like it works with other access levels.
>
> Value Types (structs, enums, etc.)
>
> Value types cannot have derived types. In this case the protected access level does not make sense and will not be allowed in their members.
>
> Protocols
>
> Protocols do not declare access level for their members. So the protected�
>
>
> [The entire original message is not included.]
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160530/08307ae9/attachment-0001.html>
More information about the swift-evolution
mailing list