macdevcenter.com
oreilly.comSafari Books Online.Conferences.

advertisement

AddThis Social Bookmark Button
Objective-C Pocket Reference

Objective-C: Dynamite!

by Andrew M. Duncan, author of Objective-C Pocket Reference
04/28/2003

"Objective-C is the result of adding object facilities to C with the goal of making programmers more productive. The result differs greatly from C++, which adds objects to C without making computers less efficient: quite a different goal."   [PC Week, November 3, 1997]

Yet Another C-Like Object-Oriented Language

So what's the big deal about Objective-C? Well, you've heard about objects, right? Encapsulating data and operations, inheriting features from ancestors, maybe even the mysterious "polymorphism." These are all commendable organizing principles for software, but there are many roads to Rome. If you have some experience with C++, Java, Eiffel, or Object Pascal then you've seen these ideas in action. What could another OO language have to offer?

Ask this question of an experienced Smalltalk programmer and be prepared for a lengthy response. Smalltalk adds to procedural programming a simple, elegant object model. In addition, Smalltalk's object mechanisms are relatively "open." That is, you can look at the way objects and classes are represented (classes are objects), and how methods are called. Objective-C was conceived as a way to add Smalltalk's object model to the plain old C language. It's remarkably successful at doing this.

Like Smalltalk, Objective-C is a simple language. Beyond its C roots, there are only a few constructs and concepts to learn, but their consequences are quite rich. Objective-C provides a simple and uniform way to encapsulate data as objects and send messages between them. Languages like C++ and Perl, with their Byzantine complexity, let you in essence construct your own dialects and idioms. But one person's dialect is another's incomprehensible gibberish. Haven't you had to debug stuff like this?

Related Reading

Objective-C Pocket Reference
By Andrew M. Duncan

Objective-C is also (like Smalltalk) a dynamic language. Briefly, this means that Objective-C defers, until runtime, decisions more static languages (such as C++) would perform at compile time. This lets you do a number of interesting things that would be awkward or simply impossible in a less dynamic language. These techniques include:

  • Adding methods to existing classes (categories)
  • Modifying the inheritance hierarchy at runtime
  • Forwarding unhandled messages
  • Refraining from specifying the type of an object

Of these, the most fundamental and most characteristic of Objective-C is the last: "typeless" declarations, also called dynamic typing. In this article, I'll discuss this topic at greater length, and explain why this distinctive feature of Objective-C is particularly advantageous.

"Message Not Understood" Considered Harmless

To be clear about this, at runtime every Objective-C object has a type: it's an instance of a particular and unambiguous class. This does not differ from any of the other popular object-oriented languages. With dynamic typing you don't need to declare in your source code what the type of an object will be, for the edification of the compiler. Objective-C supports fully static typing, just as in C++ or Java, but you can choose not to use it.

How can you get away from specifying an object's type, and why would this be a good thing, even a Good Thing? In C++, Java, and many other OO languages, you have to declare the type of the receiver--the object whose method you are calling--in code such as this:

Circle c;  // Declare type of variable "c".
c.draw();  // Compiler knows c has this method.

The compiler can guarantee (absent erroneous typecasting, of course) that the receiver's class will support the methods you call on it. There is a school of thought that holds this to be an important tool for checking the correctness of a program.

However, this sort of compiler checking is not only desirable in C++ but mandatory: not for reasons of program design, but due to the mechanism of method dispatch. When a C++ compiler encounters a method call, it emits code to index into a class-specific table whose layout it has already determined. Now, to cover its rear, the compiler must prevent the wrong table from being used at runtime. If it fails, subsequent execution is undefined; almost anything can happen, and it will always be wrong.

This is an unwelcome intrusion of implementation details into the conceptual design and practical use of a language. What's so bad about sending a message that is not understood? If a person on the street asks you for a flump, and you don't know how to respond, do you exit with a core dump? Do you feel that a Higher Power should prohibit the question from even being asked?

Objective-C takes a simpler approach to method calls: it maintains runtime information about the class hierarchy, and searches it at call time for the appropriate code to handle each method call. The speed of modern processors, hardware tricks like branch prediction and speculative execution, and Objective-C runtime tricks like caching of search results, make this method-call implementation fast enough for all but the most nested of loops. In addition, this procedure can tell when the receiver has no matching method, and so can handle this situation in a defined way. Objective-C provides default behavior for unhandled messages but lets you customize it at will.

Objective-C refers to this approach to calling methods as sending messages to objects, which describes well this outlook: inter-object communication is not like a function call, but more like mailing a letter, which gets delivered by a mechanism that is slower but more flexible than just branching to a new execution address. This makes possible all the techniques mentioned in the bullet points above. In addition, distributed programs are easier to design and implement, because message sending does not depend on one distributed component's knowing the inheritance hierarchy of another. For an example of how adherence to the C++ style of method dispatch complicates remote messaging, see the COM model.

So, Objective-C's dynamic model lets you be more loose with your data types. What good is this? Many of us have grown up with rather strictly typed languages, and have a vaguely Puritan unease with loosely typed languages. Doesn't this open up a whole can of worms? Why isn't dynamic typing "considered harmful"?

Pages: 1, 2

Next Pagearrow