Originally posted by macaroni:
Their code doesn't declare the tableView outlet as an instance of the subclass of the NSTableView but rather as the IBOutlet id.
I guess what I don't understand is how does it know to use this subclass as opposed to the parent NSTableView class.
It doesn't matter what type of variable you use to refer to an object; they are all
ids when it comes down to it (with
id being defined as a pointer to an object). You could conceivably use an NSWindow pointer to refer to it, though that would be really silly. The class of an object is an inherent property of the object. It is a subclass of NSTableView because the object in the nib is an instance of that subclass.
That's one of the most important things to learn about Objective-C -- you do not directly have objects as variables. You just reference them with pointers. You can have five different pointers all pointing to the same instance of a class. Most importantly, you can have the pointers all be
ids, and not have any idea what kind of object it actually is as long as you know what methods it will respond to. This is how protocols and the responder chain work.
I also don't quite understand why they made the controller object as an outlet for the tableView.
Because with the interface they're using, it queries the controller (which keeps track of the song listing) to find out what song it should play when you click on a row.
Honestly, I think their division of duties for the two classes is a bit silly -- the table view basically asks the controller which of its rows selected, and then proceeds to play the song itself.
Top
