Dynamic binding seems to be a lie

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

Fine

And using dot notation really comes down to a method call

But why then I can not 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 think β€œit should behave like a scripting language,” and I wonder how inflexible Objective-C seems compared to a scripting language like JavaScript.

+6
objective-c dynamic-binding
source share
3 answers

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

If you do not use dot notation, it works:

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

The above will generate a warning if the type is not an identifier, since the compiler knows that it knows the type and cannot guarantee that the send will work, but it will compile and execute.

In essence, the problem is that the compiler needs to know whether to load the structure or dispatch of Objective-C, in other words, with point notation, it should have enough information to determine the difference between an object and a scalar type.

+17
source share

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

Properties are specifically designed to disambiguate. As part of this, it was decided not to use dot versus id syntax.

In particular, he solves this situation:

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

Given the above in two separate header files, compiling [anObject length] will only warn that both header files have been imported. If only one header file is imported, then the call site will be compiled, returning the type visible in the header. If the call site was for another method, a very unexpected result will be returned.

Limiting point syntax eliminates this potential ambiguity. This is also the reason that you generally don’t see co-variant method declarations. C ABI just does not support it purely (while Objective-C does a poor job of supporting the companion object type).

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

+17
source share

Objective-C supports dynamic linking. However, you cannot use the properties of objects of type "id", but you can send him any messages. (This is probably a mistake in the current definition / implementation ... but don't leave it aside for now.)

If you did

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

then it will work. Note that you do not need to put a new line in the NSLog statement, since they are all on different lines.

0
source share

All Articles