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

5 Solutions Collect From Internet About “'Calling a method' OR 'sending a message' in Objective C”

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.tumblr.com/post/58428190187/an-observation-on-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”)

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 [foo release] 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).

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.

On a C function call, the compiler replaces the selector with a call to a function, and execution jumps in response to the function call.

In Objective-C methods are dynamically bound to messages, which means that method names are resolved to implementations at runtime. Specifically, the object is examined at runtime to see if it contains a pointer to an implementation for the given selector.

As a consequence, Objective-C lets you load and link new classes and categories while it’s running, and perform techniques like swizzling, categories, object proxies, and others. None of this is possible in C.

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.