More Thoughts on Objective-C
A follow up to the previous entry which you can read here: My Thoughts on Objective-C
I really don't understand why more languages don't include the C++ concept of constness . Objective-C sure doesn't, which is a real pain when every object is represented by a pointer to the heap. If you want a method to return one of your member objects, you have the choice of either making a deep copy (hopefully the caller cleans it up) or giving the outside world free access to modify your internal state.
Obj-C has support for threading built in, via library support and the @synchronized directive. Other useful threading primitives are thin on the ground, but are provided by libraries. Not terrible.
Bundles are such a great idea that I can't believe they haven't been stolen by everyone (I guess Java's JAR files come close to the same idea). A bundle is just a directory with a special flag so that the GUI file browser will treat it as a single file. Bundles contain both executable code and whatever resources that code needs to run, including other bundles. This is much easier than having to link stuff in at compile time, and because bundles are just directories you can access resources with normal file IO functions. Modifying an executable's resources also becomes insanely easy.
One problem is that bundles are never unloaded. This could cause problems with applications that use large plugins for short periods of time, but is probably not much of a problem in practice.
XCode is the Apple development environment. In some ways it is very nice, the project model takes some getting used to but I quite like it. Its main problem is that it is built on top of GCC and GDB, which are functional but hardly user friendly. Compared to other dev environments such as Eclipse and Visual Studio, XCode looks a bit weak. The dialog builder is nice though.
Objective-C has exceptions - yah! However, they are not very useful; Obj-C objects do not live on the stack so any stack unwinding does not release your objects (autorelease pools apparently do get cleaned up, but that doesn't get the job done).
Obj-C does support @finally blocks, so you can manually clean up your objects yourself, but this is a pain. The frameworks don't seem to use exceptions much.
I had a brief look at what happens when C++ code throws a C++ exception though Objective-C code, and vica versa - the answer is a Lovecraftian horror that you don't want to muck around with.
For the record, I thinks Java's approach to forcing exception handling is by far the best (with honourable mention to C#'s using syntax hack).
The Obj-C runtime has pretty good support for reflection - although not as convenient to use as Java or C#. This opens up all sorts of tricks that just aren't possible with C++, one of which is:
Obj-C has support of writing objects to streams and restoring them later. This is handy by itself, but MacOSX does one better and provides a way (actually multiple ways) of structuring data so that the operating system can index it automatically - this is basically how spotlight works.