This is why I now go out of my way to not even use the word Cocoa when discussing programming. I prefer to say that I build Mac apps, not that I build Cocoa apps.
Agreed. In the context of holy wars, or "What do you do?" it's been said before, the majority doesn't care about the underlying API, as long as it works, and that's as it should be. (Point 2) I'm secretly hoping that, even if it takes until 10.5.1 or 10.6, Carbon becomes fully 64-bit as well, with more and more ties between Carbon, Cocoa, Applescript, etc.
When I gave that admittedly fast and loose definition, I meant more in the lines of "What does the text say when I go to create a new project? Does it require me to link to Cocoa.h? Does it require me to link to Carbon.h?" Carbon was Apple's name for the API based on the classic MacOS. Cocoa was Apple's name for the API based on NextStep.
I'd even go so far to add in FlatCarbon as a name for the carbon that's closer to the classic style, since a modern Carbon app uses callbacks and the like, not the procedural filtering that's described back in the days of "Inside Macintosh".
As for Core Data, it's currently Cocoa-based. The Core Data Application template uses the Cocoa main.m. The key word here is currently. I'd like to see Core Data get the NSString treatment, and become something accessable via Core Foundation by Carbon as well, with NSManagedObject becoming a wrapper or a toll-free data type to CFManagedObject.
And there's two Webkits. There's a Webkit that is Cocoa, or more, a Cocoa-based wrapper. Talking about Webkit in general, I'd say it's neither Carbon nor Cocoa. If anything, it uses the Carbon RGBColor and Rect.
Does it matter? Only right after Command-Shift-N. Otherwise, no. And yes, anyone who refuses to use the right tool for the job has a future in the scone-based industry.
by Blain — Oct 02
Agreed. In the context of holy wars, or "What do you do?" it's been said before, the majority doesn't care about the underlying API, as long as it works, and that's as it should be. (Point 2) I'm secretly hoping that, even if it takes until 10.5.1 or 10.6, Carbon becomes fully 64-bit as well, with more and more ties between Carbon, Cocoa, Applescript, etc.
When I gave that admittedly fast and loose definition, I meant more in the lines of "What does the text say when I go to create a new project? Does it require me to link to Cocoa.h? Does it require me to link to Carbon.h?" Carbon was Apple's name for the API based on the classic MacOS. Cocoa was Apple's name for the API based on NextStep.
I'd even go so far to add in FlatCarbon as a name for the carbon that's closer to the classic style, since a modern Carbon app uses callbacks and the like, not the procedural filtering that's described back in the days of "Inside Macintosh".
As for Core Data, it's currently Cocoa-based. The Core Data Application template uses the Cocoa main.m. The key word here is currently. I'd like to see Core Data get the NSString treatment, and become something accessable via Core Foundation by Carbon as well, with NSManagedObject becoming a wrapper or a toll-free data type to CFManagedObject.
And there's two Webkits. There's a Webkit that is Cocoa, or more, a Cocoa-based wrapper. Talking about Webkit in general, I'd say it's neither Carbon nor Cocoa. If anything, it uses the Carbon RGBColor and Rect.
Does it matter? Only right after Command-Shift-N. Otherwise, no. And yes, anyone who refuses to use the right tool for the job has a future in the scone-based industry.