W jaki sposób zmienne i metody instancji są przechowywane w obiekcie Objective-C 2.0?

Question

W starszej wersji Objective-C, struct objc_class jest realizowany tak:

struct objc_class { 
    Class isa; 
    Class super_class; 
    const char *name; 
    long version; 
    long info; 
    long instance_size; 
    struct objc_ivar_list *ivars; 
    struct objc_method_list **methodLists; 
    struct objc_cache *cache; 
    struct objc_protocol_list *protocols; 
}; 

Tak, struct, który reprezentuje obiekt przechowuje wskaźnik do klasy obiektu, wskaźnik do super klasy tego obiektu , nazwa klasy obiektu, wersja obiektu, rozmiar informacji i instancji, lista zmiennych instancji obiektu, lista metod obiektu, pamięć podręczna obiektu i lista protokołów obiektu. Obecność tych pól w strukturze reprezentującej obiekt jest całkiem zrozumiała, ponieważ każda z nich przechowuje informacje o obiekcie.

Jednak realizacja tego samego struct objc_class Objective-C 2.0 to tak:

struct objc_class { 
    Class isa; 
}; 

Tak więc, w tej wersji objc_class, jest tylko jedno pole w struct: wskaźnik do obiektu klasa struct.

Moje pytanie brzmi: w jaki sposób są inne informacje o obiekcie przechowywanym w Objective-C 2.0, ponieważ w strukturze znajduje się tylko jedno pole reprezentujące obiekty?

Answer 1

To wszystko w nowym (no cóż, już nie tak nowym) niewrażliwym ABI.

Zasadniczo, zamiast przechowywać iVars wewnątrz struktury podobnej do używanej (która złamałaby dziedziczenie, gdyby superklasa zmieniła jej układ iVar), kompilator przenosi przekierowanie iVar na inną warstwę, podobną do objc_setAssociatedObject w środowisku wykonawczym.

To pozwala na kilka interesujących scenariuszy. Rozważmy następujący:

@interface A { // part of libA.a 
    id var1; 
    int var2; 
    float var3; 
} 

@end 

@interface B : A { // part of libB.a 
    id var4; 
} 

@end 

Teraz co, jeśli jakiś czas w dół drogi, musimy zmienić klasę A, a my musimy ustalić większą precyzję w var3 (konwersja go do long double, na przykład)?

W starszym, delikatnym ABI, zostalibyśmy wkręceni, dopóki nie zostanie zaktualizowany producent libB. Jednak dzięki temu nowemu, nieuszkodzonemu ABI mamy elastyczność, aby to wszystko zmienić, podczas gdy libB nadal działa.

Podczas gdy teoretycznie może to być wolniejsze po kilku cyklach, dodaje łatwiejsze sposoby wyszukiwania iVars w czasie wykonywania, bardziej elastyczną podklasę i obsługę różnych rodzajów iVars (na przykład __weak).