What bugs me with this whole argument is that when confronted with the wishes the Cocoa community put forward, some people respond by simply saying "Welcome to C".
That's exactly the point: We're not minding dipping into pure C from time to time, it's the part where we *write 80 lines of code to set one fucking parameter* that bugs us. It's the cryptic constants and OSTypes, the run-around-town documentation bouts and the extra lines of codes themselves.
CF code and Cocoa code can both pretty much be written by just looking at the documentation. Other C code in Mac OS X generally can't; you'll need to look at examples. This may have been the reality for a number of years now, but simply asking people to adjust means that they think the right thing to do is to never improve it, and I wonder if they're that stuck in their thinking.
And again, the above - CF and Cocoa is clear, other C APIs aren't - isn't generally because of design flaws, it's largely based on poor documentation. Look at *any* Carbon chunk and you'll see a list of functions, a list of structs and if you're very, very, lucky, a small exposition on how to put them together. Now look at a Cocoa class which often has a whole "guide" of its own, even if this has declined in recent years (NSLevelIndicator, NSSegmentedControl, NSDatePicker and NSTokenField).
Neither Carbon nor Cocoa lack thorough documentation of their own conventions and metaphors, but the general feeling is that Cocoa is way more well-documented than Carbon and in the general case produces way less code. You can wonder why.
by Jesper — Oct 07
That's exactly the point: We're not minding dipping into pure C from time to time, it's the part where we *write 80 lines of code to set one fucking parameter* that bugs us. It's the cryptic constants and OSTypes, the run-around-town documentation bouts and the extra lines of codes themselves.
CF code and Cocoa code can both pretty much be written by just looking at the documentation. Other C code in Mac OS X generally can't; you'll need to look at examples. This may have been the reality for a number of years now, but simply asking people to adjust means that they think the right thing to do is to never improve it, and I wonder if they're that stuck in their thinking.
And again, the above - CF and Cocoa is clear, other C APIs aren't - isn't generally because of design flaws, it's largely based on poor documentation. Look at *any* Carbon chunk and you'll see a list of functions, a list of structs and if you're very, very, lucky, a small exposition on how to put them together. Now look at a Cocoa class which often has a whole "guide" of its own, even if this has declined in recent years (NSLevelIndicator, NSSegmentedControl, NSDatePicker and NSTokenField).
Neither Carbon nor Cocoa lack thorough documentation of their own conventions and metaphors, but the general feeling is that Cocoa is way more well-documented than Carbon and in the general case produces way less code. You can wonder why.