I would have suggested you read "Inside Macintosh: Imaging with
Quickdraw" (available in the legacy docs), which explains all of this
very well, and is one of the best pieces of API documentation I've
ever read, but with Apple now effectively end-of-life-ing Carbon, I
probably shouldn't bother. [...]
Can you please elaborate on the comment that Apple is "now
effectively end-of-life-ing Carbon"?
I've just joined this mailing list, as someone interested in learning
to program the Mac again (after some 15 years away from Mac OS),
still trying to figure out which environment suits me best.
I have actually spent most of my time looking at Cocoa, because
absent any concrete information about it, it seemed the most like the
other high-level OOP environments available in terms of robust
libraries available for application use and simple UI construction
(via Interface Builder), as compared to other platforms (e.g.
Java, .NET, etc.).
However, even from the outset the syntax of Objective-C has put me
off (not for any good reason except my own resistance to change, I
admit :) ), and more significantly as I learn more about the object
model in Objective-C I find myself wondering if I really want to
invest a lot of effort in learning a language that is showing its
age, in that it requires a lot of explicitness that might have been
acceptable 20 or 30 years ago, but today seems outdated.
I'm specifically annoyed by what I've learned about how Objective-C
initializers have to be manually, explicitly managed relative to the
inheritance hierarchy (heck, even the ancient C++ model doesn't allow
for back-door construction via a base class constructor), as well as
the variable memory management model (do I have to release an object
or don't I? there doesn't appear to be a language-defined
requirement, instead it opts to leave that decision up to each
Reading through some of the public developer docs (I don't have a
Premiere, etc. ADC membership so am not privy to the details) for
Leopard, I gather that there will be garbage collection in Objective-
C 2.0, which will presumably eliminate the autorelease question. But
I don't see anything that suggests the object initialization model
will change, and while they make a big to-do about the new inclusion
of properties, I didn't see anything that would suggest fully-fledged
properties that allow for getter/setter code, rather than just tying
a property to an instance field.
Anyway, sorry...I ramble. My point is that at the moment, Carbon
seems like a much more appealing environment for me. Sure, the API
itself isn't OO (is it? looks pretty similar to the old Mac stuff
I'm used to, which wasn't OO), but I can use C++ to use it without
getting confused (I note that you can mix Objective-C with C++, but
since you still have to use the Objective-C syntax to access the
Cocoa API, I can easily predict how hard it will be for me to keep
the two straight). I'm going to keep on the Cocoa path for the
moment, until I've got at least one simple-but-useful application
written and have fully explored its features, but...
So far, Carbon is looking more and more appealing, and the suggestion
that it's about to be shelved is making me nervous. What has Apple
said (publicly, of course) with respect to the future of Carbon, and
is someone (me, for example) going to regret starting down the path
of learning to use the Carbon API now, only to find that Apple is
going to deprecate it some time in the near future?
Whatever insight can be offered is much appreciated. Links to online
Apple releases addressing this topic are most useful (I looked for
specifics already, but perhaps someone knows the exact URL to go
to). Thank you!
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