On Jun 20, 2005, at 6:59 PM, Bill Bumgarner wrote: On Jun 20, 2005, at 12:48 PM, Thomas Davie wrote:
On Jun 20, 2005, at 6:39 PM, Corbin Dunn wrote:
Not all outline views are table views, however, all table views are outline views, therefore outline view should be higher the the hierarchy.
All NSOutlineViews are in fact NSTableViews -- every NSOutlineView supports all of the NSTableView methods, but the reverse is not true, and it doesn't make sense to have a method like "collapseItem" on an NSTableView.
This is an implementation detail - I am arguing that the implementation is wrong... Logically a table view is an outline view restricted to leaf nodes only. collapseItem makes as much sense as it does for a leaf node in an outline view.
Actually, you are wrong. An outline view is just a table view that adds a notion of hierarchy to one of the columns. ;-)
Tomatoe, tomahto.
Whether you think the implementation is "right" or "wrong" is completely irrelevant to Cocoa development. The implementation is the way it is and it certainly isn't going to change now or any time in the near future.
Apple ships a header with the following contents. Therefore, this is law if you want to be an effective Cocoa programmer.
@interface NSOutlineView : NSTableView
I absolutely agree with you in terms of the implementation we have... If you read my original post I said NSTableView *should* be a subclass of NSOutlineView.
Thus expressing the opinion that the implementation is semantically incorrect.
It's not a point of "quick Apple, go change this" it's a case of "hang on, there's something not right here, here's an inconsistency to work around".
No subclass should ever add functionality, because this breaks the "is a" relationsip... You can't say that a object is a landmass that adds the ability to do anything else you like... You have to say a landmass is an object that takes away the ability to do a lot of things (e.g. float)
Bob |