Joe Groff
@mjtsai @curtclifton @owensd Replacing functionality for yourself is more modular than trying to dynamically change it in the framework.
-
@mjtsai Agreed. That may be a few decades in the future, but it’s better it’s discussed about now.
Curt Clifton
Michael Tsai
JΛЯΣD
Roopesh Chander
@mjtsai OTOH, a Swift framework to be used only from Swift written decades later would most likely use POP => we can override the protocol
-
-
@roopeshchander Pretty sure that’s less flexible, though I’m not super familiar with how protocols work under the hood. -
@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 … - View other replies
-
@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.
-
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.