I'm coming to the opinion that:

1: Cocoa is that which requires either a)NSObject b)anything else with an NS prefix or c) .m files.

2: It doesn't really matter. Things like Core Image and Core Foundation are part of a growing segment that is neither Cocoa nor Carbon, but is used by both, or is part of a bridge.

I think saying that it's Cocoa if it descends from NSObject is a bit broad. That would include every single Objective-C class that Apple ships.

I do agree with the NS* prefix, although I'd add the condition that classes that are specific to a single application (i.e. preference panes) would not count.

that would include AppKit and Foundation (which are the strictest definition of Cocoa) and Core Data.

Oh, and do developers really think that Core Image is part of Cocoa?

Then wouldn't WebKit be as well? Or anything that is Objective-C from Apple?

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.

Dropping the Cocoa term also goes a long way toward putting Carbon vs. Cocoa behind us. There's a whole bunch of new APIs that didn't exist back then. Most of them have an Objective-C interface, some are straight C. If you put them all under the Cocoa umbrella then it becomes meaningless.

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.

Hallelujah. The Carbon/Cocoa split has been a colossal waste of time and energy for almost a decade. An avowed OS X programmer who can't or won't handle reaching into Carbon from a Cocoa app when the situation calls for it ought to stick to Realbasic and baking scones.

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.

@Scott: Oh, and do developers really think that Core Image is part of Cocoa?

Yes, I think so. Cocoa and CoreImage are seen together so often that they are bleeding into each other.


@Nat: An avowed OS X programmer who can't or won't handle reaching into Carbon from a Cocoa app when the situation calls for it ought to stick to Realbasic and baking scones.

There are parts of Carbon that will be around until the end of time, but I don't think most folks are sitting down at this point to write a new Mac app which doesn't use NSApplication, NSView, etc. BareBones, for example, wrote Yojimbo in Cocoa.

That doesn't mean they don't use any Carbon code, it's that the application revolves around the Cocoa model (NSApplication, NSView) and likely calls into Carbon where it makes sense.

So the point is which framework is the primary model for your app, and whether you're using high level toolbox. As we've seen from oft-linked messages on carbon-dev, the high level toolbox will not be brought across to 64-bit.


@Blain: I'm secretly hoping that, even if it takes until 10.5.1 or 10.6, Carbon becomes fully 64-bit as well

Good luck with that. :)

I'd like to see Core Data get the NSString treatment, and become something accessable via Core Foundation by Carbon as well

I just don't think there's much demand for something like that, and it's a bunch of code to re-implement when Apple could be spending their time on new functionality. It's not clear who it would benefit.

Talking about Webkit in general, I'd say it's neither Carbon nor Cocoa

That's WebCore, yes? WebKit/WebCore is a bit of a different beast since it wasn't entirely home rolled and is actually present in projects that have nothing to do with Mac OS X.

Good luck with that. :)
I know, I know, it's got a snowball's chance. It's more a case of when I saw WWDC and silently not mention Carbon, I immediately thought, "So we're never going to see a 64-bit Mac photoshop, because Adobe will drag their feet even more?"

And while we're having fun with our core data and bindings, a bunch of enterprisy people are going to balk even more at doing work to make a good port. Actually, I have no data about this save Adobe and MSFT, but how many big-name cross-platform apps are actually done in Cocoa on the mac side?

As long as there's some sort of easy migration path for them, I'll rest easy.

I just don't think there's much demand for something like that, and it's a bunch of code to re-implement when Apple could be spending their time on new functionality. It's not clear who it would benefit.
Good point. I was about to say "For those still wanting carbon-based apps," and then realized that they'd be using it for cross-compatibility, so they couldn't use Core Data. Then I was about to say, "For the AppleScripts," but those run off a main.m as well.

That's WebCore, yes?
Treacherous domain name! Yes, WebCore. Even though the links are to webkit.org.

@Blain: but how many big-name cross-platform apps are actually done in Cocoa on the mac side?

Not many, though Adobe Lightroom comes to mind. Of course, it's new app they can actually sell to get a return on.

As long as there's some sort of easy migration path for them, I'll rest easy.

For C++ apps, the answer will probably continue to be to write your business logic in C/C++, and lay Cocoa on top. TextMate is an great of example of just how well this sort of arrangement can work with Objective-C++.

Blain,

That horse is dead. Flogging it won't help.

-jcr

Is it a cop-out to simply say that Cocoa is whatever Apple directly imports in Cocoa.h? My gut feeling is to say that it is anything that is inspired by the OpenStep API. So, as a Cocoa developer, I'd say things like CoreImage and WebKit should definitely be something a "Cocoa developer" would be comfortable with, even if Apple has only committed to adding CoreData to the header as of Tiger.

@jcr: Which dead horse that I'm flogging are you referring to? I've got several. Although, unrelated, some classes and methods would make awesome horse names. I can see it now: NSArrayController SetValueForKey to win, and WebKit to place, followed by CoreImage, Objective-C Biscuit, and SetKeysTriggerChangeNotificationsForDependentKey. Bay Meadows would never be the same.

@Doc: Yeah, saying something's Cocoa if and only if it's in Cocoa.h is a cop-out. But it's a slippery slope, and as others have wisely pointed out, the distinction distracts from more important issues. A Cocoa, or mac developer should have WebKit and CoreImage as tools in their belt, but they should also know regexp, bitshifting, IconRef wrangling, and others. The horse I've been flogging has been that it shouldn't matter if something's Cocoa or not, save for the compiler needing Cocoa.h, because they should know more than just one part of an API. Specialization is for insects.

@scott: but not NSProxy ;-)

For me, Cocoa is that which is the spiritual successor to OpenStep and the Yellow Box (and which is published by Apple - GNUstep is a successor to OpenStep but is not Cocoa). Which means that I define it as any high-level Mac API which doesn't make me cringe when I read the documentation.

Hi,

Any info about a book about Leopard ? like Cocoa programming by M. Hillegass 3rd editon, about objective c 2 ?

Thanks
Kamelito
PS nothing found about it on Amazon :(

I'm sure there are folks working on Leopard material, but it's been hard to write a book so far since Leopard has still been in beta.