Re: ObjC++ (and a word about Java, too ;-)
Re: ObjC++ (and a word about Java, too ;-)
- Subject: Re: ObjC++ (and a word about Java, too ;-)
- From: Thomas Lachand-Robert <email@hidden>
- Date: Wed, 5 Dec 2001 17:32:03 +0100
Le mercredi 5 dicembre 2001, ` 04:25 , Eric Schlegel a icrit :
On Wednesday, December 5, 2001, at 03:16 AM, email@hidden wrote:
I strongly believe that Carbon is just a dead end (even though it is
badly required now, due to the large quantity of existing Classic code).
The Carbon team (of which I'm a member) might take exception to that. :)
I'm curious why you consider Carbon to be a dead end.
-eric
Obviously that's just an opinion, but every time I have to look to the
documentation of Carbon, I'm scared. All these strange names FSSpec, FSRef,
kXooopsArgh, etc. I did use it some weeks ago because I needed to acces
type/creator information, and I got an headache just for this simple thing.
My code came as follows (probably not the best, but I basically copied
somewhere in the doc):
OSStatus status;
FSRef fsRef;
const char* cname;
FSSpec fsSpec;
FInfo fndrInfo;
cname = [[fullPath stringByExpandingTildeInPath] UTF8String];
status = FSPathMakeRef ((UInt8*) cname, &fsRef, NULL);
if (status == 0)
status = FSGetCatalogInfo (&fsRef, 0, NULL, NULL, &fsSpec, NULL);
if (status == 0)
status = FSpGetFInfo (&fsSpec, &fndrInfo);
if (status == 0) {
macType = fndrInfo.fdType;
macCreator = fndrInfo.fdCreator;
}
It is very difficult to understand what happens. Compare with a similar
piece in Cocoa:
NSDictionary *fattrs = [file attributes];
NSDate* date = [fattrs objectForKey:NSFileModificationDate];
NSString *group = [fattrs objectForKey:NSFileGroupOwnerAccountName];
NSString *owner = [fattrs objectForKey:NSFileOwnerAccountName];
Exception removes the need of "status", classes and dictionaries don't
need strange names, etc.
Also the organization as a whole is very difficult to understand, even for
me, who has commit a few programs on the plain old mac toolbox (ok, it was
some years ago). The comparison with Cocoa, whose structure is very simple
(there is only a small number of classes, as Ondra likes to emphasize), is
not to the glory of Carbon. It is obvious to me that a new programmer on
the mac should learn Cocoa, not Carbon.
That was not supposed to be insulting to the Carbon team. I can imagine
how difficult it is to deal with 17 years of mac history. The mac toolobox
was already quite messed five years ago, it can only become worse. So
there is a real need to suppress old code, but I can guess you constantly
have people crying "oh no, don't remove that function, it's really
necessary to me!".
The point is that IMHO Apple will not have the luxury to maintain three
OSes and three frameworks in the future (unless it grows to more that 50%
of the PC market, something we hope all, but is a far away for now).
Obviously OS9 will be trashed (and I don't regret it, even though it has a
more consistent interface than OS X), and OS X standard+server will remain.
And for the three frameworks: Cocoa, Carbon, Java? Assuming than OS 9
disappear, I can't see the need to keep Carbon.
Finally the main apps in OS X using Carbon are the Finder, Sherlock,
iTunes. Still IMHO, there are the worst, particularly Sherlock which is
just plain broken by comparison to the OS 8 version and Finder which has
still a lot of bugs/crashes,... They don't stand with Mail, TextEdit,
Project Builder or IB.
Thomas Lachand-Robert
********************** email@hidden
<< Et le chemin est long du projet ` la chose. >> Molihre, Tartuffe.