Re: Dynamic message typing problem

FROM : Michael Vannorsdel
DATE : Sat May 17 15:40:55 2008

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?