[swift-evolution] Protected access level / multiple class/struct/protocol APIs

Andrey Tarantsov andrey at tarantsov.com
Thu Apr 28 08:33:04 CDT 2016


Let me bump this thread. How do we move forward?

Here's an interface of another Swift class I've just made (slowly rewriting my Obj-C components to Swift here):

public class SoloContainerViewController: UIViewController {

    private var _contentViewController: UIViewController?

    public var contentViewController: UIViewController?  // delegates to setContentViewController:animated:completion:

    public init(contentViewController: UIViewController?) { ... }

    public required init?(coder aDecoder: NSCoder) { ... }

    public override func viewDidLoad() { ... }

    public func setContentViewController(contentViewController: UIViewController?, animated: Bool, completion completionBlock: dispatch_block_t?) { ... }

    public /*protected*/ func transition(fromView oldView: UIView?, toView newView: UIView?, animated: Bool, completion completionBlock: (finished: Bool) -> Void) { ... }

    public /*protected*/ func willTransitionToContentViewController(newViewController: UIViewController?) { ... }

    public /*protected*/ func didTransitionFromContentViewController(oldViewController: UIViewController?) { ... }

}

This is madness, we have to do SOMETHING!

This class is designed to be subclassed, with a bunch of hooks that subclasses may be interested in. Most of the reusable views and view controllers that I make look like this.

Even when I use delegates, I still forward delegate calls through overridable protected methods, based on my long history of subclassing UIScrollView (and other controls) and wishing that the subclass had access to the delegate methods.

Nobody outside of the class should be interested in those protected methods; they are not safe to call, they're override points.

And I often have to pick very telling method names, so that I don't end up accidentally calling one of those methods from outside. Sometimes that's fairly hard, like when there's a public save(), a private saveNow() and a protected saveContent().


Our best consensus the last time was:

>>> My point is that "protected" *isn't* access control. If we added it, it would have to be as an independent modifier.
> 
> Okay. So you see it as “public subclassonly”, leaving space for “internal subclassonly” (which makes sense, although not as important in practice).
> 
> I can agree with that, let's consider it a new strawman.


So how do we move forward?

A.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160428/781fe69d/attachment.html>


More information about the swift-evolution mailing list