Rixstep
	`About \| ACP \| Buy \| Industry Watch \| Learning Curve \| News \| Search \| Test`

Home » Learning Curve

Viva La Difference

A short look at Objective-C.

Additional Syntax

[ ]

The above is an Objective-C expression. Put a semicolon on the end and it's a statement.

[ ];

This is the message syntax: Objective-C sends a lot of messages. They're transported by the Objective-C runtime and are not bound in code at build time.

A full message might look like this.

[receiver message];

Where receiver is an object you want to send message to; message is thus the message.

The receiver object can have a return value, in which case the above statement can be used as an expression.

Messages can be nested.

Receiver *receiver = [[Receiver alloc] init];

Receiver would be a class and receiver a pointer to an object of this class; provided both the alloc and init methods return a pointer to the allocated and initialised object, the above statement works.

Messages can take parameters.

[receiver message:param1 anotherParam:param2];

It's the colons that distinguish the message. A message that looks like:

[receiver message:];

Is syntactically different from a message that looks like:

[receiver message::];

You use the colons to send additional parameters with a message.

You can even use commas if that's what the receiver wants.

[receiver message:param1, param2, param3];

And you don't have to have 'names' for the subsequent colons if you don't want.

The Runtime

Objective-C uses a runtime. It is functionally similar to the C runtime, but it's never baked into an application image. It works independently. Messages are sent by the runtime to the objects they target.

A message can also have a 'nil' (zero) target. This will invoke a search for a likely target along the so-called responder chain, starting at the first responder - the control, window, or app that is currently in focus - and work its way up, if need be all the way up to the app itself.

Thus a message looking like the following:

[0 copy:sender];

Will get the runtime to look for a likely candidate. If an edit control is in focus, the runtime will see if the control responds to the message.

All classes answer a basic query about responding to specific messages; if the control in question responds to a specific message, the runtime will pass the message along. If not, the runtime crawls up the responder chain until it finds a likely candidate. (If it finds no one to take the message, you'll hear a 'beep'.)

All the 'copy' messages in NS/Objective-C work the same way: they're all plain text 'copy:' and take one parameter, a pointer to the object invoking the message.

Normally this type of message does not return a value.

Messages like this - a single parameter with a pointer to the sender and of type 'void' - are called actions. Much of NS/Cocoa is about sending actions.

NS controls send actions all the time. Buttons send actions when they're clicked. And you as the program designer can determine where the action goes - and not in code, but in the actual GUI design, using the Interface Builder tool.

If clicking a specific button is supposed to invoke a specific method, there is no need to poll a message queue: you simply connect the button with your target class and method in Interface Builder.

Subclassing

There is very little subclassing done in Objective-C. This is good, for it limits the complexity of applications. Instead categories and delegation are used.

Categories are 'add-ons' to existing classes. It is very simple to declare a new function for an existing class: simply create the category's interface, declare it, and write the implementation.

Delegation is a type of notification - controls send out notification messages all the time. By assigning oneself as a delegate of a control one can get messages that notify of impending events or even ask permission to do certain things like close a window, close an app, and so forth.

NS also has a notification centre: you can register your app as a recipient of messages and specify exactly what type of messages you're interested in and who should be sending them. All other messages will not be sent.

#import

Objective-C adds the #import preprocessor directive. This is not a change in the language; it's a convenience, the equivalent of:

#ifndef _KLUDGE_ #define _KLUDGE_ /* * */ #endif

Using #import guarantees the target will be included once and only once: it'll be 'imported'.

@interface & @implementation

The interface for an Objective-C class goes in a '.h' file just like in C; the implementation, to help the compiler along, goes in a '.m' (method) file.

// myclass.h @interface MyClass : YourClass { // class variables } // class methods (declared) +(MyClass *)alloc; -(MyClass *)init; @end // myclass.m #import myclass.h @implementation MyClass // class methods (the actual code) @end

Methods that begin with a '+' are class methods; methods that begin with a '-' are object methods.

Additional Data Type

Objective-C adds a data type known as id: it's a pointer to an object (any object). The above interface for MyClass could be written:

// myclass.h @interface MyClass : YourClass { // class variables } // class methods (declared) +(id)alloc; -(id)init; @end

Objective-C & C

Objective-C makes no changes to C. None. Its syntax and use are very simple and serve to make applications simpler, not more complex; stabler, not more crash-prone; and to make a troubleshooting session easy.

Objective-C applications will run better and more reliably than their counterparts built with other architectures. And the language is a lot more fun too.

Objective-C is based on Smalltalk. It is Smalltalk but compiled and using C syntax.

Alan Kay, head of the Learning Research Center at PARC, famously quipped:

'I invented the term 'object oriented' and I can tell you I did not have C++ in mind.'

But he did have Smalltalk in mind, and Objective-C is its only direct descendant.