Re: Function calling
Re: Function calling
- Subject: Re: Function calling
- From: Ondra Cada <email@hidden>
- Date: Thu, 26 May 2005 02:12:37 +0200
Theodore,
On 25.5.2005, at 23:58, Theodore H. Smith wrote:
I've noticed that functions that return (id), can have methods
called from them.
Ammm... true, but (a) *any* functions can have methods called from
them, (b) what you probably meant was that they can have messages
sent. That's a big difference.
[item childAtIndex:index];
(And this does not have to do anything with any function at all?!?)
Here, item is actually an "id". And so we can't know what type of
object it is, or whether a childAtIndex method actually exists.
So, my question is, how does this work?
Properly :)
We (nor compiler) need to know nothing. The object knows. That's
called "encapsulation" and "polymorphism".
At runtime, an untyped object is about to be called, with a method
named "childAtIndex".
Wrong. No object is "called". A message "childAtIndex:" is about to
be sent to an object. It is completely up to it what it will do with
the message. It would most probably invoke some method, but it needs
not be "childAtIndex:" (and definitely not "childAtIndex").
OK, what information does the binary use to figure out what is the
actual function address to jump to? A list of all "childAtIndex"
methods in the compiled app?
This is a decent language, no C++ mess. The binary just translates it
to a call of a runtime function, whose arguments are the receiver,
the message, and its arguments. The runtime (effectively, there are
some tricks to make it more efficient) asks the receiver what can it
do with the "childAtIndex:" message. If it can do something (like,
it's class--or some of its superclasses--has a method of the same
name, *or* it decides to do something else with the message), all
right. Otherwise, the runtime kills the process and reports an error.
I'm assuming Cocoa does not use some kind of string based hash
table, because that would be ridiculously slow.
It does use something remotely like that (actually, strings are
compile- and link-time translated to pointers--we call them
"selectors"--and selectors are run-time cached for quick access), and
it is, as you can see for yourself, lightning fast.
Would strong typing speed things up?
Nope. Strong typing is more or less irrelevant. There are only two
things it is good for:
(a) to check for programmer's mistakes;
(b) to allow for proper argument and return value automatic casting.
Both of them are *completely* compile-time, and (but for them proper
casting of (b)) have no run-time consequence at all.
---
Ondra Čada
OCSoftware: email@hidden http://www.ocs.cz
private email@hidden http://www.ocs.cz/oc
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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