[swift-evolution] [Pitch] Let's talk about submodules

[Matthew Johnson]

> On Feb 22, 2017, at 2:04 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> On Feb 21, 2017, at 11:11 PM, Jonathan Hull via swift-evolution <swift-evolution at swift.org> 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
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution