@jckarter I mean in general—undocumented/unpromised subclassing details and non-subclassing-related bugs.
@concreteniche @jckarter Probably not as flexible. And changing classes to protocols doesn’t make the design/thinking issues go away.
-
-
@mjtsai@concreteniche You can easily wrap a conforming type and patch or completely replace its conformance if you need to. - View other replies
-
@jckarter@concreteniche Yes, but patching from the outside is limited because you can’t override anything that’s not in the protocol. - View other replies
-
@mjtsai@concreteniche The client also can't *use* anything that's not in the protocol. The interface goes both ways. - View other replies
-
@jckarter@mjtsai@concreteniche … the developer's implementation would de facto always have the last say on behavior. -
@danielpunkass@jckarter@concreteniche I think in practice protocols would intentionally not have enough surface area. - View other replies
-
@mjtsai@jckarter@concreteniche Sort of depends on how much they are embraced, I think. Stop thinking of them like a Cocoa developer… -
@danielpunkass@jckarter@concreteniche It’s not about embracing because fundamentally protocols are designed to hide details. - View other replies
-
@danielpunkass@jckarter@concreteniche Yes. The interesting thing about Obj-C is that you can call or override them all. - Show more
-
-
@mjtsai@concreteniche Protocols are far more flexible than subclassing. You aren't bolted to any existing implementation.
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.
Michael Tsai
Joe Groff
Patrick Smith
Daniel Jalkut