// override points. default is to call touch methods on the content subview. if -touchesShouldCancelInContentView: returns NO in order to start dragging after we have started tracking the content view, we don't drag and continue to feed events to the content subview. if -touchesShouldBegin:withEvent:inContentView: returns NO, we don't send events even if we don't drag
So basically, if you want to modify the behavior of how a UIScrollView drags, you need to create a subclass. Fine, that's basic polymorphism, but it isn't the way most UI behaviors are changed in Cocoa on the iPhone. Typically, behaviors are changed by the use of delegate objects, and there already is a UIScrollViewDelegate interface defined. It's not clear to me why touchesShouldBegin:withEvent:inContentView and touchesShouldCancelInContentView were not just added to the delegate.
Why is this important? Well first of all, one of the joys of Cocoa programming on the iPhone is that the object model tends to be more consistent then desktop Cocoa. Everything fits together, and you know where to look for the hook which allows you to customize your app's behavior.
Secondly, I think Apple was right to choose the delegate model over object subclassing. It's less fragile, in that you are less likely to rely on the original object's behavior being constant. And some Cocoa objects are basically impossible to subclass; for instance UIButton cannot be subclassed because it isn't a "real" object. And from a coding point of view, the delegate solves both the problem of changing behavior and intercommunicating between objects.
So, when you see a comment like the above, it sticks out like a sore thumb in what is normally a disciplined and consistent API.
