> On 16 Nov 2016, at 05:25, Shawn Erickson <[email protected]> wrote:
>
> Again my point isn't worrying about point of calling out to the delegate but
> configuring my delegator to avoid a body of work or state management that is
> unneeded if the delegate doesn't care about some mix of potential delegation
> points. I was trying to point out things to consider for those stating "why
> not just provide a default implementation that is a nop, etc." when in fact
> knowing if the delegate decided to not implement something can be helpful for
> some delegators.
>
> Anyway as stated earlier sub protocols likely are good enough however I am
> concerned about it degenerating into a single func per sub protocol in not
> atypical situations.
>
> -Shawn
>
Even if it does just become a single method, it’s not a cause for concern. In
the example before, we gave some semantic meaning to those bundles of optional
methods, so that’s a bit of a win. Also, what’s cool is that instead of the
members being optional, the conformance to the sub-protocol is what is
optional, and anything which declares conformance must implement all of the
extra callbacks. The upshot of this is that the compiler is able to validate
everything and produce an error if the extra callbacks change in the future.
For example:
class MyViewController : ScrollObserver {
func scrollViewDidScroll(_ scrollview: UIScrollView) {
// handle scroll
}
}
Now we decide to change the function signature of this optional callback (for
some reason. Let’s say we want to add a parameter…):
protocol ScrollObserver : ScrollViewDelegate {
func scrollViewDidScroll(_ scrollview: UIScrollView, from lastLocation:
CGPoint)
}
If the method was “optional”, objects would suddenly stop implementing this
requirement and it would still be perfectly valid code. However, as a
sub-protocol, we get proper validation and the compiler will produce an error
until we update everything to handle the new signature.
I think this problem has actually come up with @obj-c protocols. Some
signatures changed in Swift 3 due to API overlay improvements and some
conformances silently failed to resolve, IIRC.
- Karl_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
