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.
Qt pre-dates "modern" C++ with good template support---this was a business
decision at the time, not a slight against C++. You achieve similar
(perhaps identical) results using a recent C++ compiler, without resorting
to a metacompiler. (Boost.Signals is a good start, and I've used it to
great success in implementing Qt-like signals and slots.)
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.
Apples and oranges (cf. the "C++ is Bad for UI APIs" inference below). MS
didn't invent C# to replace C++, evidenced by the fact that they have
a managed C++ that runs on the same .NET framework as C#.
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.
The choice for Obj-C predates Cocoa---it was also used in NeXTStep, and its
GNU "successor", GNUStep. Furthermore, you can achive similar "delegate"
and "category" functionality in C++ via delegate and decorator design
patterns, without the extra overhead of Obj-C's garbage collection.
And since we're all offering opinions on Obj-C, I'd argue that Obj-C's OO
syntax in general is quite unintuitive as far as OO languages go...
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.
If you've ever debugged a modern Carbon application, you'll notice that
many of the C-interface HIToolbox functions call into C++ classes that look
surprisingly like those from the HIFramework example.
Barring the current "Is 64-bit Carbon Viable" conversation, it does not
look to me like Apple has has decided that C++ is a poor choice for an
application framework. Also, WinSTL (a modern alternative to MFC) is alive
and kicking, so I think C++ is still the language of choice for at least
a few Windows programmers...
Cheers,
Demian
_______________________________________________
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
This email sent to email@hidden
--
Demian M. email@hidden .--N--. Science can purify religion from
Pgh. Supercomputing Ctr._____ ..\ R /.. error and superstition; religion
300 S. Craig, Pgh., PA 15213_ ....B.... can purify science from idolatry
psc.edu/~dnave___412-268-4574 ...PSC... and false absolutes.-Pope J.P.II
_______________________________________________
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
