> On Feb 22, 2017, at 2:04 AM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> 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.
If I understand this strategy correctly it doesn’t prevent client code from seeing `UIGestureRecognizerSubclass` but it does require an explicit `import UIKit.UIGestureRecognizerSubclass` in code that depends on it making the inappropriate dependency easy to detect. Is that what you have in mind? > > -- > Brent Royal-Gordon > Architechies > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
