Objective-C 2.0 Note

1. The compiler also builds a "metaclass object" for each class. It describes the class object just as the class object describes instances of the class.

    But while you can send messages to instances and to the class object, the metaclass object is used only by the runtime system.

2. Initializing a Class Object

    The runtime system sends an "initialize" message to every class object before the class receives any other messages and after its superclass has received

    the "initialize" message. 

    The "initialize" method must call just once.

    Remember that the runtime system sends "initialize" to each class individually. Therefore, in a class's implementation of the "initialize" method, you must

    not send the "initialize"  message to its superclass.

3.@package

    On 64-bit, an @package instance variable acts like @public inside the image that implements the class, but @private outside.

This is analogous to private_extern for variables and functions. Any code outside the class implementation’s image that tries to use the instance variable will get a link error. This is most useful for instance variables in framework classes, where @private may be too restrictive but @protected or @public too permissive.

    By default, all unmarked instance variables are @protected.

4. Extensions

    Class extensions are like "anonymous" categories, except that the methods they declare must be implemented in the main @implementation block

    for the corresponding class.

5.  @synthesize instructs the compiler to synthesize the relevant accessors;

     @dynamic informs the compiler that you will proviode the methods yourself at runtime.

     You can use the @synthesize and @dynamic directives in @implementation blocks to trigger specific compiler actions.

    Note that neither is  required for any given @property declaration.

    The default value is @dynamic. If, therefore, you do not specify either @synthesize or @dynamic for a particular property, you must

    provide a getter and setter(or just getter in the case of a readonly property) method implementation for that property.

6. Property Re-declaration

    If you declare a property in one class as "readonly", you can redeclare it as "readwrite" in a class extension, a protocol, or a subclass.

7. self

    If you want to access a property of self using accessor methods, you must explicitly call out self as illustrated in this example:

        self.age = 10;

    If you don't use self, you access the instance variable directly. In the following example, the set accessor method for the age property

    is not invoked:

        age = 10;

8. Exception Handle

    use the -fobjc-exceptions  flag switch of GCC

    You are not limited to throwing NSException objects. You can throw any Objective-C object as an exception object. The NSException class provides

    methods that help in exception processing, but you can implement your own if you so desire.

9. Forwarding

    Sending a message to an object that doesn't handle that message is an error. However, before announcing the error,

    The runtime system gives the receiving object a second chance to handle the message. It sends the object a "forwardInvocation:" message with

    an NSInvocation object as its sole argument -- the NSInvocation object encapsulates the original message and the arguments that were passed with it.

    

    You can implement a forwardInvocation: method to give a default response to the message, or to avoid the error in some other way. As its name implies, 

    forwardInvocation: is commonly used to forward the message to another object.

To forward a message, all a forwardInvocation: method needs to do is:
■ Determine where the message should go, and
■ Send it there with its original arguments.
The message can be sent with the invokeWithTarget: method:
- (void)forwardInvocation:(NSInvocation *)anInvocation
{
    if ([someOtherObject respondsToSelector:
            [anInvocation selector]])
        [anInvocation invokeWithTarget:someOtherObject];
    else
        [super forwardInvocation:anInvocation];
}

10.  Dynamic Method Resolution

There are situations where you might want to provide an implementation of a method dynamically. For example, the Objective-C declared properties feature (see “Properties” (page 45)) includes the @dynamic directive:
          @dynamic propertyName;
which tells the compiler that the methods associated with the property will be provided dynamically.
You can implement the methods resolveInstanceMethod: and resolveClassMethod: to dynamically provide an implementation for a given selector for an instance and class method respectively.
An Objective-C method is simply a C function that take at least two arguments—self and _cmd. You can add a function to a class as a method using the function class_addMethod. Therefore, given the following function:
          void dynamicMethodIMP(id self, SEL _cmd) {
              // implementation ....
}
you can dynamically add it to a class as a method (called resolveThisMethodDynamically) using

resolveInstanceMethod: like this:

@implementation MyClass

+ (BOOL)resolveInstanceMethod:(SEL)aSEL
{
       if (aSEL == @selector(resolveThisMethodDynamically)) {
             class_addMethod([self class], aSEL, (IMP) dynamicMethodIMP, "v@:");
             return YES;
       }
        return [super resolveInstanceMethod:aSEL];
}

@end

Forwarding methods (as described in “Forwarding” (page 112)) and dynamic method resolution are, largely, orthogonal. A class has the opportunity to dynamically resolve a method before the forwarding mechanism kicks in. If respondsToSelector: or instancesRespondToSelector: is invoked, the dynamic method resolver is given the opportunity to provide an IMP for the selector first. If you implement resolveInstanceMethod: but want particular selectors to actually be forwarded via the forwarding mechanism, you return NO for those selectors.