Dynamic binding seems like a lie.

Question

Objective-C uses dynamic binding: that is method calls are resolved at runtime.

Fine.

And use of dot notation really boils down to a method call

But, why then, can't I do something like this:

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];


  // Intercept the exception
  @try
  {
    @throw [ NSException 
            exceptionWithName:@"Exception named ME!" 
            reason:@"Because i wanted to" 
            userInfo:nil ] ;
  }
  @catch( id exc ) // pointer to an exception object?
  {



    //NSLog( @"%@ : %@\n", exc.name, exc.reason ) ; // ILLEGAL:  Request for member 
    // 'name' in something not a structure or union..
    // If objective-c uses dynamic binding, and dot notation
    // boils down to calling the getter, then
    // WHY do I have to cast to the concrete type here?

    // Only works if I cast to the concrete type NSException*
    NSException* nexc = (NSException*)exc ;
    NSLog( @"%@ : %@\n", nexc.name, nexc.reason ) ;



  }



  [pool drain];
    return 0;
}

When I hear "dynamic binding" I'm thinking "so it should behave like a scripting language", and I'm surprised how inflexible Objective-C seems compared to a scripting language like JavaScript.

Answer 1

Objective-C does support dynamic binding. However, you cannot use properties on objects of type 'id' - but you can send it any messages you want. (This is probably a mistake in the current definition/implementation ... but let's leave that aside for now.)

If you did

NSLog(@"%@ : %@", [exc name], [exc reason] );

then it would work. Note that you don't need to put a newline on an NSLog statement, as they're all on separate lines anyway.

Answer 2

You are confusing the runtime and the compiler. The runtime has no problem coping with that. The issue is that dot notation (which is syntactic sugar) requires type information for the compiler to disambiguate between Objective-C objects and C structs.

If you don't use dot notation it works:

NSLog( @"%@ : %@\n", [exc name], [exc reason]) ;

The above will generate a warning if the type is not id since the compiler knows it does know the type and can't guarantee the dispatch will work, but it will compile and run.

Fundamentally the issue at hand is the compiler needs to know whether to generate a structure load, or an Objective C dispatch, in other words, with dot notation it needs to have enough information to determine the difference between an object and a scalar type.

Answer 3

Dynamic binding is not synonymous with dynamic typing. C is a strongly typed language and, in particular, the type of an argument or return value is critical and can significantly impact code generation.

Properties are specifically designed to eliminate ambiguity. As a part of that, the decision was made to not allow the dot syntax to be used against id.

Specifically, it addresses this situation:

@interface Foo
- (short) length;
@end

@interface Bar
- (unsigned long long) length;
@end

Given the above in two separate header files, compilation of [anObject length] will give a warning only of both header files have been imported. If only one header file has been imported, then the call site will be compiled returning the type seen in the header. If the call site were for the other method, a very unexpected result would be returned.

The limitation on the dot syntax eliminates this potential ambiguity. This is also the reason why you don't generally see co-variant declarations of methods. The C ABI just doesn't support it cleanly (with that said, Objective-C does a poor job of supporting object type co-variance).

In reality, Objective-C developers rarely use the id type. Specific type declarations enable the compiler to significantly improve its code validation.