[Osx-nutters] Call Me Fishmeal.: Pimp My Code, Part 12: Frozen in Carbonite.

[David Cake]

At 5:00 PM -0700 5/10/06, Shawn Erickson wrote:
>On Oct 5, 2006, at 2:56 PM, Kevin Callahan wrote:
>
>>
>><http://wilshipley.com/blog/2006/10/pimp-my-code-part-12-frozen-in.html>
>>
>>"What I want to do, with this post, is encourage Apple to finally 
>>move those necessary but neglected frameworks all the way to Cocoa."
>
>Apple should make well designed/consistent API in C and then build 
>Objective-C frameworks on top of those. Using only Objetive-C would 
>limit the mix of non-Objetive-C development environment on Mac OS X.

	You have to read the article. More or less, this is what 
Apple has been doing with CoreFoundation, CoreData, CoreImage, etc, 
which its clear Wil thinks is a good idea.

	Wils big issue is with Carbon style of C, not not C itself. 
I agree, really. Stuff like QuickTime is a ghastly, poorly documented 
mess, with a lot of stuff in the idiosyncratic old Carbon style, 
which as Wil says is hard to use, poorly documented, and generally 
out of touch with modern programming practice.
	Wil is also correct when he says -
- some areas of Carbon, notably QuickTime, use enormous amounts of 
low level code, largely not really documented, to accomplish things 
that should be available via a useful high level API (ie one API for 
all directly connected camera devices).
- some programmers in the Carbon team, when directed to do Cocoa 
wrappers, do a bare minimum, often resulting in something that isn't 
really useful. This results in basically a pointless bit of 
timewasting. You might think there is a Cocoa API, you'll try to use 
it, you'll quickly realise all sorts of things that you thought the 
API could do (because you've seen other apps do them) aren't 
available, and then you'll have to learn the clumsy poorly documented 
Carbon API anyway.
ie the Cocoa QuickTime wrappers before 10.4, which didn't include 
functionality as sophisticated as as setting the playback point of a 
movie to point other than the start or the end.

	For that matter its not that hard to access Obj C only stuff 
from pure C. Its messy and complicated, but not really more so than 
the stuff Wil is complaining about. But the point is more that the 
Cocoa-ish C code like CoreFoundation is an order of magnitude saner 
than very Carbonish C code like QuickTime.

	Though Wil is wrong about using FSRefs instead of string path 
equivalents. FSRefs aren't perfect, but string paths are exactly an 
example of one of those 20-30 year old programming techniques he 
complains about elsewhere. A CoreFoundation style nicely wrapped 
FSRef equivalent (with inbuilt path compatibility for the truly 
obstiante) would be the answer, not paths. Aren't we supposed to be 
looking forward to more database semantics in our file systems, Wil? 
But this is a minor bit of occupational grumpiness - one that weakens 
his case significantly, as it makes him look a lot like one of the 
Avie led Cocoa zealots that tried hard to push Apple towards doing 
things the NeXT way in the early days of Mac OS X - the problem being 
that they did so regardless of the merits of the MacOS approach.

	It is worth mentioning that QuickTime does seem to be a 
special case all of its own. QuickTime is a morass of scary badly 
maintained code, often written hurriedly to support two or three 
devices then more or less abandandoned from that point on, with all 
future users just being thrown the same ball of crufty sample code. 
QuickTime has many undocumented things, many things that work 
incredibly obscurely, many things that have deep hidden magic you 
will never understand. And much of it that I am pretty sure no one at 
Apple understands any more either.
	And I think QuickTime, as a whole API, will never be fixed. 
Lots of bits of it are either unmaintained to the point of usefulness 
(Flash compatibility is at least 2, I think 3 major versions behind), 
effectively orphased (QuickDraw 3D support), or otherwise broken. I 
would not be at all surprised if only those parts that are either 
traditionally widely deployed, somehow link in with iPods/iTunes or 
pro apps like FCP, or are mpeg 4 related get any maintenance work at 
all. It would be nice if Apple would just deprecate huge chunks of 
it, and then fix the rest - except many of the chunks that should be 
deprecated are used by very particular bits of very particular apps 
etc.

>
>I personally want Apple to take another year if they want in getting 
>64 bit support out in Mac OS X since the switch to 64 bit can be 
>used as a way to clean out old API in favor of new.

	They'd be sacrificing a lot for minimal gain. A staged 
changeover (with at least one full release, hopefully 10.5, that 
supports old API and new) is the way to go.