Can you please elaborate on the comment that Apple is "now
effectively end-of-life-ing Carbon"?
Welcome Pete,
I've moved this reply over to a thread that is discussing these sorts
of things.
§
Executives, because of the scope of their responsibilities,
necessarily have to base their decisions about resource allocation on
the opinions of advisors.
Most unfortunately, it appears that language racists have held the
advisor positions at Apple for the last few years.
The erroneous assumption of these alleged language racists was that
developers who were using Carbon would just naturally gravitate to
Cocoa because of the supposedly better facilities. When that didn't
happen, and it was becoming clear that the Carbon team was doing more
with less, a typical gambit, not unknown in history, was hatched and
put into play.
Thus, the Carbon framework development team has been deliberately
starved of resources. In order not to alienate long standing Mac
developers, Carbon and Cocoa were initially portrayed as equals, then
increasingly, Cocoa was given the leading edge, and now we're
arriving at the phase where Carbon is being marginalized. To the
point that, for no technical or financial reasons, 64-bit support for
Carbon UI is now supposed to be arbitrarily dropped for Leopard even
though it was announced last year that Carbon would be 64-bit.
What it looks like to many folks on this list is that the above steps
were cunningly contrived to mislead and were couched in terms that
would make it difficult to sue for breach of promise.
Which might lead one to a deduction that the kind of mind that would
think to deceive third party developers in the above fashion would
even deceive its own employees by similar tactics. I mean if I was an
Apple employee, I'd sure be thinking about a forensic audit. Starting
with pension fund management, the expense accounts of certain
advisors, and any contracts said advisors authorized.
So it's my opinion that the idea of Carbon termination should undergo
a rethink. Much better for advertising too, because then Apple can
play up that the choice of best platform in the known universe is
between Carbon and Cocoa, not between Mac and Windows.
§
Lastly, I'd like to note that since I've done a bunch of coding in
Tcl, I don't have any problems at all using bracket notation in
Objective-C. While one can't fail to notice the continuity carried
through in the design of the Foundation/AppKit frameworks, I'd much
prefer that kind of follow-thru be done in CoreFoundation/Carbon and
have Objective-C be just one of the high level languages available to
access it.
Philip Aker
email@hidden
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 object's implementation).
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:
http://lists.apple.com/mailman/options/carbon-dev/email@hidden
