I recently had a discussion with a friend of mine whom I work with regarding C++ vs. Objective-C. I told him about GNUstep and also showed him Gorm. I explained the dynamic features of Objective-C and compared it to smalltalk and Java.
When I showed him some images of Gorm from the GS website I told him that Gorm could not be done in C++. He took some offense to this and immediately asked me "May I ask why you believe this couldn't be done?"
I explained that, it's because Gorm uses does several things which depend on the dynamic nature of Objective-C in order to do it's job. Here is a quick summary of the features of Objective-C which Gorm uses:
1) Categories - many categories, these are used in Gorm to do the following things
a) add the name of the inspector class for each type of inspector to the class itself so that it can be looked up easily. Mainly adding the extensions from the IBObjectAdditions.h protocol.
b) Also used for editors inspectors.
2) Loadable bundles - The palettes, which actually make up a large percentage of the code in Gorm are actually loadable bundles. These can be loaded when the application starts or during runtime.
3) Protocols - Many many protocols in Gorm. :)
4) Dynamic binding - As such, per #3, it's important to be able to call objects without knowing thier true class.
So far as I know C++ is incapable of doing #1, and is also incapable of #3 and #4. He went on to explain that it could be done in C++ if the modeller was a "code generator" to which I responded, but mine doesn't generate any code at all. :)
Subscribe to:
Post Comments (Atom)
-
Are we really going to fall for it again?
-
I wanted to make this post to make it clear to the community regarding GNUstep's position on the new Swift language. If the langu... -
When NeXT still existed and the black hardware was a thing, Steve Jobs made the announcement that OPENSTEP would be created and that the ob...
6 comments:
It can be done in C++, but not without the help of additional tools. Either you use something like Qt's QObject system, which gives C++ objects some more dynamic capabilities such as a limited support for
introspection, signals/slots and properties. Or alternatively you could also use a library which is able to gather meta-information from binaries and header files. AFAIK the latter has only been done for C, not for C++, though.
If something can be "done" in a given computer language, it can be done in ANY computer language. It may be very difficult, but, it can always be done.
Sorry, one clarification. It can be done in ANY computer language that is 'Turing complete'
Are you claiming Romanji is English, too? No, C++ can't do it, swallow that. If you still want to call it C++.
Tim, please educate me, can we send any possible message to any possible object with QT's QObject system at GUI designer level? That is, don't you have to implement signals/slots for every method of QObject subclasses you want to use in the designer? If not, then that's a higher layer over C++, not C++. The same goes for Obj-C as a layer over C.
One thing to remember is, with Gorm you don't even have to recompile the object model, so gathering header files can't compete with Gorm's methods.
Gaining meta-information from the binaries (which I was told that it isn't possible with C++) could be a way to go, but as in my previous comment, I don't know if I should call it C++ and it sounds like a romantic dream to me. Not to mention that GTK's GObject can also do that as well.
For Thomas Zander, please try to understand tim's comment before you made such claims.
This funniest thing is that all of your needs are already covered by Qt (which is the basis of KDE and is C++).get your ex back !venapro reviews
Post a Comment