[swift-evolution] [Draft] Allow declaration of abstract functions and properties on classes
vinivendra at gmail.com
Fri Feb 26 13:03:22 CST 2016
> > > The other problem with the protocol-based solution is that it leads to conceptual leakage. The protocol you need to declare lives outside the class(es) that need it.
> > >
> > > The ActivityViewControlling protocol is now available universally, even though it's interface is only relevant to a certain portion the class hierarchy.
There wouldn’t really be a conceptual leakage. If we treat the protocol as a replacement for the abstract class, we see that both implementations amount to pretty much the same thing.
If before we wanted an abstract class MyController, subclassed as MyControllerA and MyControllerB, we could ‘substitute’ it (using Brent’s suggestions) with MyProtocol.
MyProtocol would have the same (universal) scope as MyController, so users could reference the generic MyProtocol at will (and not have to specify individual subclasses).
In a similar manner, we don’t think of MyControllerA and MyControllerB so much as subclasses of my controller anymore, but as implementations of MyProtocol. If we ever “forget” to add protocol conformance, the issue would be instantly found at compile time, since the new subclasses would be incompatible with all references to MyProtocol in our code and would also lack the possible extensions provided by MyProtocol.
More information about the swift-evolution