Re: Function calling
Re: Function calling
- Subject: Re: Function calling
- From: Erik Buck <email@hidden>
- Date: Wed, 25 May 2005 19:55:59 -0400
Wow. I love a question I can answer with an essay.
Your first misunderstanding is revealed when you write "I've noticed
that functions that return (id), can have methods called from them."
In the example you cite, no "function" is called at all, and return
values have nothing to do with your question.
Objective-C adds the concepts of messages and methods to the ANSI C
or C++ programming languages.
- A message is an abstract idea and few assumptions are made about
messages. For example, any message can be sent to any object
including an anonymous object. The sender of the message might not
know the class of the receiver. The receiver might not even be in the
same program as the sender (distributed messaging).
- A method is a collection of executable code that can be invoked by
an object in response to the receipt of a message.
Messages promote object reuse by minimizing the dependencies between
objects. The less one object knows about another, the better chance
the objects can be reused separately. Messaging enables communication
between objects without dependencies.
The Objective-C runtime always chooses at run-time which method to
invoke in response to the receipt of a message. It does not matter
what static type is specified at compile time. The id is a pointer
to "any object", and there is no difference at run-time whether the
receiver of a message is of type id or any more precise type. The
exact same messaging logic is used in either case.
The way messaging works is well described in of all places a section
titled "How Messaging Works" http://developer.apple.com/documentation/
Cocoa/Conceptual/ObjectiveC/LanguageOverview/chapter_3_section_6.html
See also the rest of http://developer.apple.com/documentation/Cocoa/
Conceptual/ObjectiveC
http://www.toodarkpark.org/computers/objc/
Here is a brief summary:
A message is identified by a scalar data type called a selector
denoted by the SEL typedef provided by Objective-C. Different
messages have different selectors, and the same message has the same
selector no matter how, where, or when the message is sent or what
object (if any) receives the message. Note: it is perfectly fine to
send any message to nil (no object) as long as the expected return
value from the message is of a suitable type or is ignored.
Strings can be converted to selectors and selectors can be converted
to strings. The compiler converts the string message names in your
source code into selectors. You can also use NSStringFromSelector()
and NSSelectorFromString() to do the job yourself at runtime. See
also the @selector() syntax of Objective-C.
At run-time, the method to invoke after receiving a message is
determined by a look-up in a table that maps selectors to methods
implementations denoted by the IMP typedef used with Objective-C. If
the receiver of a message is nil, no look-up is performed. With
Apple's Objective-C runtime, If the receiver does not have an IMP
that corresponds to the selector, the -forwardInvocation: method of
the receiver is invoked giving the receiver a chance to handle the
message anyway. The receiver might forward the message on to a
different object that does understand the message or it might just
report an error. Other runtimes use a similar methods to "forward"
messages.
The ability to send any message to any object is one of the great
strengths of Objective-C and it is essential for the implementation
of much of Cocoa.
-------------------
Finally, I like to make the following observations:
In C++, non-virtual member functions calls are resolved to an address
within the compiled executable when the executable is linked.
In C++, virtual member function calls are resolved to an index within
a table of addresses within the compiled executable when the
executable is linked.
In Objective-C, all messages are dynamically dispatched. There is no
corollary to a non-virtual member function except possibly a plain C
function.
In Objective-C, all message sends are resolved to a call to the
objc_msgSend() function call or one of the similar functions provided
by the runtime when the executable is linked.
In C++, both the type of the object who's member function is being
called and which member function is being called MUST be known at
link time.
In Objective-C, neither the object that receives a message nor the
message that is sent need to be know at link time.
-------------------
Now, just consider the implications of not needing to know the
receiver or the message at link time...
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden