Mailing Lists: Apple Mailing Lists
Image of Mac OS face in stamp
Re: [OT] Carbon and WWDC'07
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OT] Carbon and WWDC'07



On 2007-03-20, at 22:52:44, Eric Schlegel wrote:

Objective C is one of the primary implementation and API languages for Mac OS X. Apple is not making any effort to provide both procedural and object-oriented APIs for every new technology; that would, quite simply, be a waste of time and money.

I for one don't think so. Having multiple API sets nurtured and cared for is more characteristic of "the most advanced operating system in the world". And let's not revisit the folly where at one time Pascal was the one true king on the Mac and now it's being said the same of Objective-C.


Personally, I find the Carbon implementation much more appealing. It seems to me that the strength of Cocoa is in the class design, not necessarily the Objective-C means. That type of design, as currently reflected, adapted, and implemented in the CoreFoundation/Carbon combo offers me a lot of flexibility. And I think it's foolish of whoever is making the decisions at Apple not to put everything possible into the lowest possible layers first so it becomes available simultaneously in Carbon and Cocoa. I mean Apple's currently got a fairly flush wallet from iPods, so why not pump some back into multi-brain OS X?

What CoreFoundation is currently missing though, is integration with the OSType concepts that dominate in components (i.e. OSA, AppleEvents, QuickTime, Input methods, etc.) and CarbonEvents and a partial lack of types (i.e. 100% coordination with XML Schema data- types). A deft insertion of those facilities in CoreFoundation would mean for instance an ease of AppleScript-ability for Carbon apps that would easily match what is now available in Cocoa.

Part of what I find poor in Cocoa has been recently put by Finlay Dobbie:

Re: Rules for dynamically loaded bundles, CFEqual, CFDictionaryFindBuckets1b crash w/ dangling applicationID reference

The issue Cocoa has is mostly to do with it being unfeasibly tricky to extract things from the Obj-C runtime class hierarchy (classes in the bundles would have to go away - what happens to instances? what about categories, what do you do with those (since you no longer have the original method implementations - you could cache them and return them on unload, but then you could have weird behaviour if you unloaded things in an order other than they were loaded, etc...)

That is to say it doesn't have namespaces so it could unload a namespace rather than the intertwined and convoluted mess Finaly talks about.


And if Cocoa's so smart, how come it took 4+ years to get Cmd-Shift-E (Enter Replace string) into PB/Xcode?


My 2ยข.

Philip Aker
email@hidden _______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >[OT] Carbon and WWDC'07 (From: "Carlos Eduardo Mello" <email@hidden>)
 >Re: [OT] Carbon and WWDC'07 (From: Eric Schlegel <email@hidden>)



Visit the Apple Store online or at retail locations.
1-800-MY-APPLE

Contact Apple | Terms of Use | Privacy Policy

Copyright © 2011 Apple Inc. All rights reserved.