What gives you that idea? Our C++ app framework wraps all the
standard Carbon/HI controls with C++ subclasses. We can call
GetLongValue or GetUnicodeValue on of those wrappers without knowing
or caring what type of control it actually contains. For almost all
of the Carbon Events we care about, the base class automatically
installs the handler, then routes any subclass can override a virtual
method to handle events in a special way if needed. Our windows are
also C++ wrappers for WindowRefs, with subclasses for dlogs,
palettes, and overlays. I might be biased, but I like writing UI
stuff in C++ a heck of a lot more than anything else, including Obj-
C, because we also get multiple inheritance that we use all over the
place to great effect. Does Obj-C 2.0 offer that yet?
Yeah, but look at all that code you had to write in order to do it.
Wrappers around everything, a complex multiple inheritance
architecture. And if you bundled this as a close source library, could
I get the same functionality out of it that you have? I'm skeptical.
Let's take a look at what three difference, modern, OO GUI API's have done:
1) QT: They didn't find C++ sufficient either, which is why you have
the macro compiler. In order to connect controls with their actions,
they implemented a signal/slot mechanism.
2) C#: Here MS went out and reinvented Java. One of the big things
they have for extensibility is the delegate system, which is more like
QT signals/slots than it is the Cocoa paradigm. Also, partial classes
help hide from you all the code VStudio is generating to make the
whole thing work.
3) Cocoa: Apple co-opted an existing language. Once again, a delegate
model enters the picture for people who want to tweak the
functionality of a control without completely subclassing it. But I
think Obj-C wins over the others because of the category support,
which allows you to add methods without subclassing.
In each case these guys looked at what C++ had to offer. They looked
at the failure of MFC. And then they decided to go down a different
road. To me that's pretty convincing evidence that the
Carbon/Win32/gtk style APIs are not up to task, and that C++ is not
the best language to build a new one on.
_______________________________________________
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
