>> I've actually had multiple cases in Objective-C code where this feature
>> (some object behaving differently depending on wether or not a delegate
>> method has been implemented) has prevented me from implementing features the
>> easy and obvious way. In those cases I resorted to implementing
>> 'respondsToSelector:'. So I'd argue that optional protocol methods encourage
>> this type of behavior, which imho is bad API design. If you need to behave
>> differently for some types of delegates (or whatever else your protocol
>> represents), a separate method to call to determine how to behave is much
>> simpler and better to use.
>
> +1. This is exactly the same thing I mentioned regarding the fast path for
> row height in UITableView. The fact that it depends on whether or not the
> delegate implements heightForRowAtIndexPath is a bad design decision.
Yes, but please observe that the form of optional methods that we're discussing
here is limited to avoid the case you mention (I hate that problem as well,
very very much).
A.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
