Michael Tsai
@curtclifton @jckarter @owensd I don’t see how it advances the platform to have everyone relying on middleware instead of the frameworks.
-
@roopeshchander Pretty sure that’s less flexible, though I’m not super familiar with how protocols work under the hood.
Joe Groff
JΛЯΣD
Roopesh Chander
@mjtsai Protocol methods are always override-able, even if you assign a subtype to a protocl-type. Like in:http://nomothetis.svbtle.com/the-ghost-of-swift-bugs-future …
-
-
@roopeshchander Yes, but only overridable within your code, right? -
@mjtsai If the protocol is public, it should be possible to override across modules (I’ve not tested this though). -
@mjtsai But, like I said, whenever there’s a final class in the hierarchy, it becomes unoverridable … - View other replies
-
@mjtsai Except, when the exposed type is a protocol (not class), it can be overridden even when the implementation is through a final class. -
@mjtsai So, yes, it’s possible that in a protocol-oriented Swift framework, we might get a different type of dynamism to achieve this.
-
-
@mjtsai On second thoughts, there has to be a class somewhere in the hierarchy, and it’s possible to make that final.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.