Clam down guys! I happen to have used both C++ and Obj-C... When I first use Obj-C it was a horrible verbose mess of a language, which seemed to lack the more obvious design of C++, but after using Obj-C a lot, I came to undertand the design goals of the designers.
I do understand the design aims of Objective-C, I just think it's a hideous abortion of a language, especially as a superset of C.
Even the most basic OO operations have a syntax a drunken alien could not have made a worse hash of. Instantiating an object on the free store:
Foo* foo = [[Foo alloc] init];
The left hand side of the above assignment is C, right hand side is... gibberish.
Or, in v2 parlance:
Foo* foo = [Foo new];
A bit better, but what the feck is with the square bracket syntax?
Now, in C++
Foo* foo = new Foo();
The only unusual thing above from a C perspective is operator
new.
I now think that C++ is the more logical evolution of C, but that Obj-C is a purer vision of what an OOP programming language is supposed to be. Neither is a better language, they simply have different design goals.
I wouldn't call either language an evolution of C. They are both supersets that aim to provide support for paradigms other than basic procedural programming. C++ gives you a strongly typed OOP model with a wide gamut of OOP features many other languages have shied away from (things like multiple inheritance and operator overloading spring to mind), generic programming and metaprogramming, but comparatively weak support for reflective programming. From this we get strongly typed, compile-time dominated optimisation that leads to efficient code but with some limitations on runtime flexibility.
Objective-C brings what I'd define as "narrow" OOP, akin to the Java model of singular inheritance with interfaces and reflection. From this we get a somewhat weaker typed system with emphasis on runtime flexibility rather than performance. Having runtime loadable classes and the like is certainly nice.
Both are decent aims; my argument is purely about the syntax. Objective-C's OOP syntax is simply alien if you come from a C background. One cannot claim with any credibility that resembles traditional C.
Consider a simple C function used as an interface to some structure to discourage direct poking about:
struct Foo {
int bar;
};
int Foo_getBar(const struct Foo* foo)
{
return foo->bar;
}
In C++, you might have reworked Foo as a class and have a simple inline getter:
class Foo
{
private:
bar;
public:
int getBar() const
{
return bar;
}
};
The basic C function syntax is still perfectly recognisable within the class context. The only unusual thing above is the const qualifier for the code block which provided a guarantee that calling this method will not change the instance of the class. In the end, a nice simple method that will always be optimized away by the compiler to a safe, read-only access to the member value 'bar';
Then we get Objective-C (there may be a few errors here, I haven't used it for years):
@interface Foo {
int bar;
}
-(int)getBar;
@end
There's already a fair degree of WTF going on here, but we aren't done yet since as you don't generally have simple inline methods, you must implement your interface elsewhere:
@implementation Foo
-(int)getBar
{
return bar;
}
@end
So, the class to which a member function belongs is delimited with '@', the indication that the function is not an instance method but a class method is the '-' prefix, return type is parenthesised and none given for the arguments taken (if any). How could that look less like C, other than by removing the braces and elemental type names?
Lastly, where are the accessor levels? Even Java has those.
I'm sorry but as far as C goes, all of this is just an utter abortion.
Personally I now prefer Obj-C, as I fid it easier to come back to a project after not lookin at it for a while and get back into it without having to reread my design notes!
