In article <these3rt0only-7554ED.13013214062007@[EMAIL PROTECTED]
>,
Roelf Toxopeus <these3rt0only@[EMAIL PROTECTED]
> wrote:
> Are they moving Carbon out?
If they are it's going to take years just to deprecate, let alone
eliminate. There's a lot of stuff you simply can't do in straight Cocoa
today. And a lot more that's either horribly inefficient, or horribly
convoluted to make efficient.
> http://www.apple.com/macosx/leopard/technology/64bit.html
> http://lists.apple.com/archives/carbon-dev/2007/Jun/msg00260.html
I would note that:
1) Some parts of Carbon already deal with 64-bit values.
2) The comment is about Carbon specifically. There's no indication that
there will be no 64-bit procedural code. I think the thing to question
is what parts of the Carbon API as it exists today would benefit from
"64-bitness" - what that would actually mean to them.
> I had an inclination about this already looking at the new Quicktime,
> Core 'this and that' frameworks, which are written in Obj-C and thus
> Cocoa. Some have an interface, so you can access them from outside
> Cocoa, others not. You'll have to use Quicktime (sic).
> Also Core Audio has new functions and warnings things will be
deprecated.
> The current Carbon API references are loaded with deprecate warnings.
That's because the current Carbon API has a lot of legacy and
(im****tantly) redundant cruft.
I wouldn't read too much into this quite yet.
|
