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.
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
