More Objective-C annoyances

Having to put square brackets around object messages is a royal pain in the butt. If you have:

[MyClass alloc]

and then you want to initialize it was well, you have to go back to the start and add an additional open bracket like this:

[[MyClass alloc] init]

In Smalltalk this is simply:

MyClass alloc init

Actually in Smalltalk this is really:

MyClass new

As the method "new" is defined on Object to be:

self new init

Objective-C has this same method defined. The book I'm reading states that it is better to do these operations separately so that you understand that two distinct events are occurring. That is complete and utter crap, of course.

Also, why is the base class NSObject instead of just Object?

Oh, another annoying thing about defining your instance variables in a separate .h file where you define the interface (of which the instance variables are not part of) is that when you reference the instance variables in the .m implementation file, they don't exist in that file! You either have to remember this information or go searching for it. Both options are dumb and result in less productivity. This is why object-oriented languages were developed to replace C. Why make all the same mistakes in the new language?

More Objective-C

Another annoyance is the use of the * to indicate that the variable is reference or a pointer, instead of the actual variable location. This is a pet-peeve of mine in C and C++ as well. For objects, this is just ridiculous, since it is required to be a pointer. It should just be convention that all object variables are references and not require the extra, annoying syntax. It just gives you an error if you leave it out anyway.

All variable names are references as far as the programmer is concerned. Whether that is a direct memory location or a pointer to a memory location in the heap should be handled by the compiler and causes no conceptual problems for the programmer. Java does this. Smalltalk does it as well, handling immediate objects (primitives in Objective-C or Java) under the covers. There is no need to make a high-level language look like assembly language.

I believe this practice came about because people didn't know how to write proper parsers, but there is probably a better reason. It seems so cumbersome.

Objective-C

I'm just starting to learn Objective-C so that I can develop an iPhone application. To learn it I'm reading Programming in Objective-C 2.0, online at Safari Books. The book states that Objective-C is patterned after Smalltalk and I'm quite familiar with Smalltalk programming, having developed in it professionally for years. I'm going to spew my first thoughts on this language here and it will be interesting to maybe look back and see how wrong I was.

In Objective-C (OC for shorthand) you send a message to an object like this:

[ receiver message ]

In Smalltalk you do it like this:

receiver message

Why the extra brackets for OC? Are parsers more primitive? The parser programmers more lazy?

Objective C seems to have primitive types, making the language a mixture of objects and non-objects. Smalltalk has no such mixture. Obective C requires the programmer to declare the type of the variable. Smalltalk does not. It seems to be that Objective C is closer to Java or C++ than Smalltalk.

OC seems to like extra syntax. For example, I see strings used like this:

    @"The fraction is"

I realize that this creates an NSString object and maybe that is more special than a regular String object (if one exists), but if not, what's the purpose of the @? I guess to denote the different type, but why would this book not use a simple string in the early examples? My guess is that this is the simple string and then I wonder why the heck is the @ used?

OC seems to carry over the royal pain in the butt separate header file from C++ and C. Forcing the programming to separate the interface from the implementation when we can have the compiler do this for us. Why force the programmer to do this extra work?

When defining a class in OC you have an interface section like this:

@interface Fraction: NSObject
{
  int  numerator;
  int  denominator;
}

-(void)   print;
-(void)   setNumerator: (int) n;
-(void)   setDenominator: (int) d;

@end

The part between the curly braces are the PRIVATE instance variables of the object. They have NOTHING to do with the interface of the object, yet they must be declared in the interface section?! Either this book is extremely bad or this language made a ridiculous choice here.

Also, notice how the arguments to the method setNumerator and setDenominator are declared. The type is specified with parens around them? Why add the extra syntax? Poor parsing again?

At first glance, there seems to be plenty to be annoyed with in Objective-C.