'Calling a method' OR 'sending a message' in Objective C

Question

In C or any ECMAscript based language you 'call a public method or function' on an object. But in documentation for Objective C, there are no public method calls, only the sending of messages.

Is there anything wrong in thinking that when you 'send a message' in ObjC you are actually 'calling a public method on an Object'.?

Answer 1

Was taught this in my Java class. I would say they only have realistic differences in multithreaded scenarios, where message-passing is a very legitimate and often-used technique.

Answer 2

Theoretically, they're different.

Practically, not so much.

They're different in that in Objective-C, objects can choose to not respond to messages, or forward messages on to different objects, or whatever. In languages like C, function calls are really just jumping to a certain spot in memory and executing code. There's no dynamic behavior involved.

However, in standard use cases, when you send a message to an object, the method that the message represented will usually end up being called. So about 99% of the time, sending a message will result in calling a method. As such, we often say "call a method" when we really mean "send a message". So practically, they're almost always the same, but they don't have to be.

A while ago, I waxed philosophical on this topic and blogged about it: http://davedelong.com/blog/2009/10/04/observation-objective-c

edit

To directly answer your question, there's usually nothing wrong with saying "calling a method" instead of "sending a message". However, it's important to understand that there is a very significant implementation difference.

(And as an aside, my personal preference is to say "invoke a method on an object")

Answer 3

No, there's nothing at all wrong with thinking of it like that. They are called messages because they are a layer of abstraction over functions. Part of this comes from Objective C's type system. A better understanding of messages helps:

full source on wikipedia (I've picked out some of the more relevant issues)

Internal names of the function are rarely used directly. Generally, messages are converted to function calls defined in the Objective-C runtime library. It is not necessarily known at link time which method will be called because the class of the receiver (the object being sent the message) need not be known until runtime.

from same article:

The Objective-C model of object-oriented programming is based on message passing to object instances. In Objective-C one does not call a method; one sends a message. The object to which the message is directed — the receiver — is not guaranteed to respond to a message, and if it does not, it simply raises an exception. Smalltalk-style programming allows messages to go unimplemented, with the method resolved to its implementation at runtime. For example, a message may be sent to a collection of objects, to which only some will be expected to respond, without fear of producing runtime errors. (The Cocoa platform takes advantage of this, as all objects in a Cocoa application are sent the awakeFromNib: message as the application launches. Objects may respond by executing any initialization required at launch.) Message passing also does not require that an object be defined at compile time.

Answer 4

Because of Objective-C's dynamic messaging dispatch, message sending is actually different from calling a C function or a C++ method (although eventually, a C function will be called). Messages are sent through selectors to the receiving object, which either responds to the message by invoking an IMP (a C function pointer) or by forwarding the message to its superclass. If no class in the inheritance chain responds to the message, an exception is thrown. It's also possible to intercept a message and forward it to a wholly different class (this is what NSProxy subclasses do).

When using Objective-C, there isn't a huge difference between message sending and C++-style method calling, but there are a few practical implications of the message passing system that I know of:

1. Since the message processing happens at runtime, instead of compile time, there's no compile-time way to know whether a class responds to any particular message. This is why you usually get compiler warnings instead of errors when you misspell a method, for instance.
2. You can safely send any message to nil, allowing for idioms like [release foo] without worrying about checking for NULL.
3. As @CrazyJugglerDrummer says, message dispatching allows you to send messages to a lot of objects at a time without worrying about whether they will respond to them. This allows informal protocols and sending messages to all objects in a container.
4. I'm not 100% sure of this, but I think categories (adding methods to already-existing classes) are made possible through dynamic message dispatch.
5. Message sending allows for message forwarding (for instance with NSProxy subclasses).
6. Message sending allows you to do interesting low-level hacking such as method swizzling (exchanging implementations of methods at runtime).