The difficulty is methods in ObjC are dispatched messages rather than
hardcoded functions so going from call to method execution has some
hidden intermediate steps. And there can be more than one method with
the same name from different classes/protocols. This is one of the
pillars to ObjC's runtime flexibility as it allows methods to be added
and checked during runtime. Further complicating the matter is the
differences in how PPC and 32 bit Intel pass arguments (why your
previous code may have worked on PPC and not Intel; PPC passes args
via registers, Intel 32 via the stack). Not to mention any future
differences of new archs.
Lets say for instance you had the method:
- (NSString*)doSomethingWith:(int)val;
and you used it like:
[obj doSomethingWith:(float)val];
The compiler knows the argument is supposed to be an int so it will
cast val to a float and then to an int before passing it on to the
method. Casting the arg doesn't change the method's accepted arg
type. When the types are unknown the compiler has to assume the types
(like id for return values) and will cast args to those assumed types,
which may not be compatible for the actual type. For instance, if the
compiler assumed int for the arg type, stores val as an int on the
stack (Intel 32), and the actual method expects a float, it will load
the stack value believing it's a float type and end up with a weird
value. Int 5 and float 5.0 are totally different at the binary
level. On PPC the method would probably use the wrong register.
The method declaration is how the compiler knows what form to write
the var to the stack as or which register to put it in.
On May 17, 2008, at 5:55 AM, Julius Guzy wrote:
The id type is completely nonrestrictive. By itself, it yields no
information about an object, except that it is an object.
Since the id type designator can’t supply [the object's methods,
variables] to the compiler, each object has to be able to supply it
at runtime.
every object carries with it an isa instance variable that
identifies the object’s class—what kind of object it is.
Objects are thus dynamically typed at runtime. Whenever it needs to,
the runtime system can find the exact class that an object belongs
to, just by asking the object. Dynamic typing in Objective-C serves
as the foundation for dynamic binding, discussed later.
<end quote>
Assume a file which contains a call of the form
int tempVar = [idValue methodIdentifier:param];
Assume there is no header file to give information about
methodIdentifier and its parameters.
The problem for the compiler is to determine the return type and the
type of the parameter "param".
We have already established that (one way) this problem can be
resolved is if the calling file includes the header of a dummy class
which includes a method called "methodIdentifier:" of type say float
and that returns an integer say.
Could not the compiler have been given the exact same information
through coercion viz:
int tempVar = (int)[idValue methodIdentifier:(float)param];
This does not work but what is wrong with this line of reasoning and/
or why could the system not make use of coercion as part of a
dynamic typing mechanism?
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
