> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution > <[email protected]> wrote: > > There is one major use case which I see all of these proposals failing to > handle (although that may be intentional for some designs), is where you have > something internal to the type, but you still want to allow > subclasses/extensions outside the framework (which need that information) to > access it. An actual example of this is UIGestureRecognizer. This class is > designed to be subclassed outside of the framework, but it hides things like > setting the ‘state' from client code (without hiding it from subclasses). > This is important, because if a client sets the state directly, then it > results in either undefined behavior, or an infinite loop. Other languages > use ‘protected’ and ‘friend’ to accomplish this.
Yeah, that's a use case I've thought about. I *think* that, if extensions in other submodules can add `open` methods, it can be done: 1. Create a submodule (or several) containing `UIGestureRecognizer`'s normal APIs. 2. Create a `UIKit.UIGestureRecognizerSubclass` submodule containing the subclass-only APIs in an extension. 3. In the top-level module, declare the main submodule `@exported open`, and declare `UIKit.UIGestureRecognizerSubclass` `open`. There are holes in this idea—particularly, the setter on the `state` property—but I *think* you could do something along these lines. -- Brent Royal-Gordon Architechies _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
