> On Feb 27, 2016, at 3:59 PM, Ben Kennedy <b...@zygoat.ca> wrote: > > >> On 27 Feb 2016, at 11:17 am, Carl Hoefs <newsli...@autonomy.caltech.edu> >> wrote: >> >> Yes, that works, thanks! I just thought there might be a "preferred" way to >> do it. I guess I was hoping for something like: >> >> [myTableView selectRowAtIndexPath:indexPath >> animated:YES >> scrollPosition:UITableViewScrollPositionMiddle >> triggersDelegateCallback:YES]; > > What gain would that afford you, though? > > I believe that the table view API is designed this way to afford the > programmer control and flexibility. Perhaps your didSelectRow:... > implementation calls some private method to do the business logic, say -[self > fireTheRockets]. In that case, you could simply call fireTheRockets directly > here instead. > > By contrast, the delegate API provides your code a means to act on external > events (user input) brokered by the table view. Perhaps in such a case there > is additional UI-related work not suitable for inclusion in fireTheRockets. > > This decoupling enables you to separate these concerns. >
Except that it doesn’t follow. There is no design necessity that the object programmatically setting the selection is the same object as the delegate, nor that those two objects know anything about each other. Also if a delegate implements such a delegate call it is signaling that it needs to know every selection change regardless of how it is accomplished (since it has not way of knowing in advance how it was accomplished, unless you decide to couple the two objects). This results in a much more reliable and extensible decoupling since no other object should know those internal signaling mechanics and should have confidence that any other object interested in the selection will be dutifully notified. In fact, this is how NSTableView works. Why UITableView doesn’t, seems worthy of a radar. Best, Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
