Can you please elaborate on the comment that Apple is "now
effectively end-of-life-ing Carbon"?
Read the archives of this list. Especially the thread about 64-bit
Carbon. There have also been several blog postings summarizing what's
happening and some Apple engineers have publicly commented. I'm not
going to go any deeper because 1) Pretty much everything has been
said on this list and 2) I don't want to say stuff I'm not supposed
to due to NDA.
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),
Not quite sure I follow you. In C++ you also have to call through
to the base class constructor unless you have no parameters to pass.
And it's a feature that you can decide what object to create without
the caller having to know they're getting another object. That way,
class clusters integrate much more easily.
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 object's implementation).
You may want to listen to my explanation of Cocoa memory management
(and memory management in general, including debugging memory) on the
http://LateNightCocoa.com Podcast. There's really a very simple set
of rules behind this, and apart from one or two tiny exceptions
(which are probably only there for historical reasons, i.e. look like
they were mistakes), everything follows these rules. IMHO, compared
to C's manual memory management using NewPtr()/DisposePtr() and the
likes, ObjC's reference counting/pools system saves you a lot of
hassle worrying about ownership. It's the next best thing if you
can't have garbage collection.
I gather that there will be garbage collection in Objective-C 2.0,
which will presumably eliminate the autorelease question. (...)
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.
Not sure I understand you here, but again, searching the web will
unearth some blogs with a bunch of information gleaned by some people
from the public GCC sources. That should answer most of your
questions about ObjC 2.0, I'd think. E.g. http://theocacao.com/
document.page/288 (lots in the comments)
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),
Actually, IMHO the Classic Toolbox was definitely OO, if you don't
count that it didn't actually use an OO language. You even had
objects (structs) with inheritance (GrafPtr -> WindowPtr ->
DialogPtr), override methods (at least a few, via the StdProcs or
QDProcs or whatever they were called), and the "storage" parameter to
NewWindow() let you "subclass" them. Carbon has added to that with
its Carbon Event Handlers and HIObjects.
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).
Actually, I've found the opposite to be true: Since ObjC looks so
different, it has been easier for me to keep them apart in my head.
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...
Get Aaron Hillegass' book. It's the only way to learn Cocoa, IMHO.
If you're already familiar with an OO language, it shouldn't take you
more than a couple days. The ObjC language is only a few added
constructs on top of straight C. Not half as complex as C++ and Java.
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?
Cheers,
-- M. Uli Kusterer
"The Witnesses of TeachText are everywhere..."
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Carbon-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
