Objective C is an object-oriented extension of ANSI C that provides the programmer with a Smalltalk-style object model. Unlike C++, typing in Objective C is dynamic by default. Objective C has been used to build networked systems such as NeXT's Distributed Objects. It is well suited to GUI programming because it allows calls to methods to be dynamically generated by any object. Budding GUI coders will want to look at the OpenStep spec to see how NeXT designed theirs.

Objective C is an extension to ANSI C that allows for a rich, dynamically typed and bound object oriented model. It allows for greater runtime flexibility than C++. Java is very strongly based on it, and it is the basis for the wonderful object-oriented framework that underlies OpenStep and Apple's Rhapsody and now MacOS X. It is easy to learn as well.

Objective C manages to create a fully object oriented language just by adding a couple of things to to C. It' s very simple. The more important adition is the [] operator: everything you put in there is of the form [OBJECT MESSAGE]. Like this:
id p;
p=[Person alloc];
[p init];
The classes are defined this way:
@implementation Person : Object
	char *nombre;



The thing is that this language is fully dynamic. You can even ask the user which method of an object you should call. Method names are not checked at compile time, and object can catch all messages/methods they don' t undertand and so you can easily make object proxies. The object model is similar to Smalltalk and Java.

Some more notes: The dash at the begining of the method declaration indicates an instance method, a plus sign would indicate a class method (like c++ and Java static methods). Note that you create an instance of an object by calling a class method of the class, which is in turn an object!

Now you know Objective C, go and code something.

I'm a (classic) MacOS developer making the (rather painful) switch to MacOS X. I've got around 9 years experience developing with C++. I'm really comfy with C++, the standard C++ library (with the ultra-nice STL) and various compilers, frameworks and APIs. I consider myself an extremely good C++ developer. I gained all my C++ skills through self study, practice (of course) and by using the tremendous C++ resources out there: from other C++ developers, the host of C++ books that have been published over the years, and various other places like web-sites and mailing lists.

What scares me about Objective C is that the infrastructure behind it is lacking. There aren't any (AFAIK) currently published Objective C books out. No C++ books aimed at beginners, no reference manuals, no excellent GURU books like Effective C++ and More Effective C++. There aren't many good Objective C tutorial web-sites around, I haven't found a Objective C FAQ anywhere and I have yet to be introduced to a programmer in the workplace with Objective C on his resume.

This makes it hard if not impossible to gain the Objective C skills needed to develop commercial software. I'm hoping as Apple forces Objective C and Cocoa down the throats of Mac developers worldwide all these resources will begin to appear.

Until then I'm sticking with C++, my nice C++ frameworks and a good C++ compiler.

Update: Sept. 23 2002. Objective-C is (and has been for over a year) been my language of choice for Mac OS X development and I'm working on a couple of pieces of shareware in Cocoa. Go figure!

This is the genealogy of the programming language Objective-C:

Objective-C is a child of C and Smalltalk.
Objective-C was first known as Objective-C in year 1983, and has not changed much since that time.

This genealogy is brought to you by the Programming Languages Genealogy Project. Please send comments to thbz.

Objective C is also known as objc or objective-c, and is in my humble opinion wonderfully elegant. It is now the focal language Apple is pushing for new Mac OS X development; though in theory they consider Java to be about equivalent in their eyes, Java frequently lags in tools support and is treated as a second-class citizen by some OS X APIs.

Objective C was created by Brad Cox in 1983, but nothing really happened with it until 1986, when Brad and Andrew Novobilski released a book on it, and the good people at NeXT (who were all Smalltalk junkies), decided to use the language as the foundation of their flagship operating system. Following this turning point, virtually overnight, Objective C had completely failed to take the world by storm, a status it still holds today. Meanwhile-- partly because of the reluctance of those who controlled the language to loosen their direct copyright control of it (GCC wasn't able to get a proper objc implementation until 1992) and partially because of a variety of other reasons-- pretty much everyone not developing for (and on) NeXT machines was quickly scared away into the arms of the also emerging and less-purely-oo C++.

With time, realizing that more and more the cult following for NeXT products was being driven by developers who had become addicted to the highly RAD aspects of the NeXTStep API and used it to make customized programs for corporations, NeXT began porting their API to other operating systems as a very (financially) expensive runtime and collection of development tools, trying to package NeXT as a platform-independent industrial-strength Objective C development environment. This continued until they were bought by Apple.

Objective C the language is still fairly inextricably intertwined with the NeXTStep API, which has been renamed to Cocoa now that Apple owns NeXT. Objc makes NeXTStep/cocoa what it is, and NeXTStep/cocoa makes objc worth using. ObjC is not, of course, welded to its API the way that java is (except for three to five classes that are at this point basically part of the language)-- but, since wants to write a class library from scratch, ObjC development for anything other than a NeXTStep workalike is rare.

NeXTStep has two halves, the Foundation and the AppKit. The first is a practically-essential-they're-so-useful collection of base classes that basically amounts to some kind of StdLib, the things that NeXT believed should be a part of any ObjC runtime. The second is NeXT/Apple's specific implementation of a GUI API written on top of that Foundation-- and in my opinion, it's the best damn GUI API ever written. Not everything you would want to write in Objective C would involve the AppKit, but near as i can gather, other than that, these days, all Objective C development uses a form of the NeXTStep foundation.

At this point "some form of NeXTStep" would be either GNUStep (Which is a GPLed re-implementation of NeXTStep; they are still in progress, and their AppKit is said to be buggy, but their Foundation is solid enough to develop for), which runs on linux, windows, and many Unices; or Apple's Cocoa (Which is YellowBox (Which is NeXTStep renamed) renamed), and only runs on Mac OS X; or WebObjects, an Apple product which is something a little different, runs just about anywhere, and seems to actually kind of resemble something between Zope, J2EE, and the Everything Engine. Once Mac OS X makes its market presence really well felt and Cocoa begins to attract developers away from Carbon in significant numbers, and once GNUStep becomes developed enough that it becomes a viable development platform for linux and windows software (or if mac users' wildest dreams come true and apple releases Cocoa environments for linux/windows..).. well, lets just say things are going to get very very interesting.

To clear up Nicola's writeup above just a bit: the @implementation, which you usually see dumped alone in its own .m file, is usually accompanied by an @interface, which goes in an accompanying .h file. the @interface is exactly the same, except instead of implementing the method as Nicola does above, you simply place method prototypes. If you have the { variable list } attached to the @interface, you are allowed to omit it from the @implementation. Between the two, if you are trying to link into an object library, Objective C only requires the @interface's .h file-- the @implementation's .m file does not need to be distributed, and you can just distribute compiled binaries for that the way you do with C++.

Following is a little metanode of everything that objective-c adds to the C language. Let me know if you find anything relevant which i do not list here. Read these, and you basically understand the language; however, these nodes really should NOT be used as material for learning the objective-c language. They are more meaningful as reference material for those who already grasp the language basically and need to clear things up to themselves.

If you want to learn the objective-c language, there is an excellent book-- so good that any attempt to emulate it on everything2 would be pointless-- available for free at http://devworld.apple.c om/techpubs/macosx/C ocoa/ObjectiveC/ObjC.pdf (minus spaces). I suggest you read it, even if you have no use for objective-c-- it is a very quick read, and understanding the way objects are dealt with in objective c may give you a better understanding of how to deal with them in other languages.

A couple more things: If you wish to learn the NeXTStep/GNUStep/Yellow Box/Cocoa API-- which you probably will have to in order to do anything in objective c-- there is good coverage of all classes at:

  • http://devworld.apple.c om/techpubs/macosx/C ocoa/Reference/Foundatio n/ObjC_classic/FoundationT OC.html
  • http://devworld.apple.c om/techpubs/macosx/C ocoa/Reference/Applicatio nKit/ObjC_classic/AppKitT OC.html

These could be noded, but i would consider this a bad idea-- they are comprehensive and long, and if the e2 version got out of date it would be hellish to update. (There are writeups on id/NSObject, however, and a writeup on NSString might be worthwhile as well.) Just read them offsite. If you wish to use the open, cross-platform GNUstep rather than the mac os x-tied cocoa, http://gnustep.org/resources/documentation.html will help you understand where the two APIs differ.
And finally, a couple more URLs you may find interesting:

  • C++ compared to objective c: http://www.mactech.c om/articles/macte ch/Vol.13/13.03/Ca ndObjectiveCCompared/
  • Java as compared to objective c: http://www.wosource.com/ObjCvsJava.html
  • Smalltalk, Eiffel, and objective c contrasted: http://www.dekorte.com/O bjective-C/Documentation/2_C omparisons/Comparisons.html

Objective-C is a programming language. It is the predominant language used for writing end-user graphical software for computers running the Mac OS X operating system, and is effectively mandatory for writing commercial software for the iPhone.

Objective-C is a superset of the C language. In other words, it has all of the semantics and other features of C, as well as various additions, including:

  • objects
  • classes, which are themselves objects
  • single-inheritance subclassing
  • optional dynamic typing (for objects) using the generic type "id"
  • dynamic messaging
  • protocols, a means of declaring a collection of messages which will be implemented later
  • categories, another means of declaring a collection of messages which can optionally be implemented immediately or later, allowing arbitrary extension of the behaviour of existing classes without having to subclass
  • object and class introspection/reflection


The fundamental construct which distinguishes Objective-C and its use is the dynamic message. A dynamic message is one in which the message name, the receiver, and the arguments can all be varied at runtime. Moreover, messages can be archived as objects which can be transmitted over a network (using the Distributed Objects system) or recorded to disk (though there is no built-in facility for this in Mac OS X or the iPhone OS—it's not hard to do it in a custom manner, however).

To enable the dynamic messaging features of Objective-C requires a support library, the obj-c runtime. The library includes a collection of structures and functions which allow the dynamic creation and inspection of classes, including the ability to add or replace methods at runtime, and, most importantly, the ability to associate functions with method selectors and to invoke method implementations in response to the sending of messages.

Most programmers writing Mac or iPhone applications will use the features of the runtime indirectly. The vast majority of classes are written and created at compile time, and most objects are instantiated from classes which reside in the various Objective-C frameworks (a kind of dynamic library) included in Mac OS X, such as AppKit, Foundation, Core Data, Calendar, and more. (Many of the same frameworks also appear on the iPhone, with the key exception of AppKit, which has been replaced with UIKit, which is more streamlined and specially designed for use with the smaller, multi-touch-enabled screen).

The most distinct feature of programming in Objective-C is the use of the messaging syntax, for example:

int foo = [array count];

which will return an integer with the number of objects in an object of type NSArray. the "count" is the message selector, which is like the name of the message. A message is more than a name; it also includes a receiver and arguments, if any.

Here is an example of a message send statement containing an argument:

id obj = [array objectAtIndex:0];

A key distinction in the terminology of Objective-C is the message as opposed to the method. Messages are sent, while methods are invoked when a message is received. It is entirely possible to send a message to an object which does not understand it (i.e., which does not implement a method corresponding to the message selector). In that case, the runtime will instead invoke a default method (described later).

It is improper (though common) to misuse the term "call" when describing the invocation of methods. Functions, defined using the same language syntax as in ANSI C, are called. Methods are invoked. However, a method is implemented as a normal C function: when a it is invoked, the underlying function is executed in the same way as a normal function—it is called by the runtime (specifically, by the objc_msgSend function, often the most called function in an Objective-C program). But to acquire a good natural sense of how Objective-C programs behave, it is always good to remember that Objective-C code sends messages, and those messages are received—indirectly—via the runtime, and the results are only defined at runtime.

Messages can be sent to normal objects (instances of classes), or to classes themselves (which are also called class objects, or factory objects). When defining a class, if the class object itself responds to a message, the method is declared prefixed with a "+" character, similar to this example:

+ (id)alloc;

whereas a method intended for instances of the class start with a "-" character:

- (id)init;

Between the +/- and the selector is the return type. The default return type is id (I say "id" like the Freudian subconscious, but it's probably more correct to say "eye-dee"; I didn't learn from greybeards, but from the Apple ]documentation] on the Internet). Thus the return type is optional, although it's nowadays considered bad form to write it like this:


In order to send a message to a class, you either use the class name explicitly, or you can define a variable of type "Class", and set that variable by sending the -class message to any object (regular instance or class object).

A method which takes an argument is declared like this:

- (id)objectAtIndex:(int)idx;

The colon defines an argument. Multiple colons mean multiple arguments, one per colon. Here are two declarations for methods taking multiple arguments:

- (void)initWithObject:(id)obj forKey:(id)key;
- doSomething:arg1 :arg2;

The first form follows the customary—though verbose—technique of prefixing the colon with descriptive text. Text ending with a colon is called a keyword. After each keyword is an argument, including an optional type (default is, again, id). The second example eschews the text in the second keyword, as well as the return and argument types. The name of an argument is mandatory.

Messages can be nested to make more concise statements. The most common nesting is see in object creation. The customary way to create an object is to send a class the +alloc method, which returns an instance, which can be sent the -init method, as follows:

id myWindow = [[NSWindow alloc] init];

This gives you a window object, at which point, you could make it appear onscreen, as follows:

[myWindow makeKeyAndOrderFront:nil];

"nil" is like NULL -- it is the zero pointer, but of object type. The message -makeKeyAndOrderFront: is an example of an action message. Many classes in the AppKit framework are subclasses of NSResponder. NSResponder is an abstract class which defines common behaviours of views, controls, windows and other objects which respond to user interface actions like key presses and mouse events.

When you are done with your window, you should free it from memory (unless you have enabled automatic garbage collection), by sending it a -release message, like so:

[myWindow release];

Now, your window object is gone. Don't send it any more messages, or you will probably crash your program. Cocoa, as Apple calls their Objective-C development environment, only added support for automatic memory management (garbage collection) in Mac OS X 10.5 (Leopard), and it is optional. It only works for Objective-C objects, not C structures and not Core Foundation types; the former you must still allocate with malloc() or a similar function (if you want them to live beyond the current stack frame), and the latter you create and destroy with Core Foundation functions.

For more information, check out Apple's Mac OS X developer library, including: Objective-C: a Primary and Object-Oriented Programming with Objective-C.

I almost forgot: what happens when you send a message to an object which does not implement the corresponding method (i.e. that has no member function which is bound the the selector for that message)? The runtime invokes -doesNotUnderstandSelector:, which is a method defined on the root class, NSObject (and which throws an exception). However, you can override -doesNotUnderstandSelector: in your custom subclass to do whatever you want, including sending the message to a completely different object.

Log in or registerto write something here or to contact authors.