Warum müssen wir in Objective-C [MyClass-Klasse] machen?

Question

In Objective-C, können Sie Klassenmethoden mit aufrufen:

[MyClass aClassMethod]; 

Und Sie können mit einer Instanz der Art abfragen:

[someInstance isKindOfClass:[MyClass class]]; 

Aber warum müssen wir [MyClass class], und nicht einfach zu tun, bieten MyClass wie folgt aus:

[someInstance isKindOfClass:MyClass]; 

gibt es einen Grund, dass der Compiler in Ordnung ist MyClass mit der Begegnung als Empfänger (ein Zeigertyp) aber nicht als Argument? Ist es eine Einschränkung beim Parsen der Sprache? Oder vielleicht eine Einschränkung des Compilers?

Answer 1

Ooooh ... Spaß Frage. Die Antwort ist ein c-ism.

Bedenken Sie:

@interface MyClass : NSObject 
@end 
@implementation MyClass 
@end 

Nun sagen Sie:

... 
MyClass *m = nil; 
... 

In diesem Zusammenhang hat der Compiler MyClass als Typdefinition sieht. Die * besagt, dass die Variable m eine pointer to a hunk o' memory that contains one (or many -- don't forget your C pointer-fu) MyClass instances ist.

Mit anderen Worten, MyClass ist ein Typ.

Aber im Zusammenhang mit so etwas wie:

[someInstance isKindOfClass: x ]; 

x muss ein R-Wert oder, in menschlicher Hinsicht sein, der Wert eines Ausdrucks. Ein Typ kann jedoch nicht als R-Wert verwendet werden.

Das funktioniert [MyClass class] ist eigentlich ein bisschen ein Hack, sowohl in der Sprache und dem Compiler, in dem die Grammatik ausdrücklich erlaubt, dass ein Typ-Name der Nachrichtenempfänger (das Ziel eines Methodenaufrufs sein).

Und, wie in der Tat, können Sie tun:

typedef MyClass Foo; 
.... 
[MyClass class]; 
[Foo Class]; 

Es wird alle Arbeit. Sie können jedoch die folgenden nicht tun, aber die Fehlermeldung Beleuchtung:

[NSUInteger class]; 

Fehler: 'NSUInteger' ist kein Objective-C Klassenname oder Alias ​​

---

Jetzt , warum nicht Sonderfall überall als bloßer Name?

Das kollidiert Typnamen und rvalues ​​und Sie am Ende müssen schlucken etwas wie [foo isKindOfClass: (MyClass)]; während barfing auf [foo isKindOfClass: (MyClass *)]; die dann auf Typcasting Territorium in einer eher unbequemen Weise eingreift.

Answer 2

Denn was die isKindOfClass erwartet eine „Klasse“ und das ist, was von dem Aufruf zurück erhalten: [MyClass class]

Answer 3

Meine erste Blick Antwort ist, weil [MyClass Klasse], um ein Objekt vom Typ Klasse zurück und MyClass nicht erben aus der Klasse ...

Answer 4

MyClass ist nicht vom Typ Class.

[MyClass class] ist vom Typ Class.

Wenn Sie mit Java vertraut sind, ist das Konzept das gleiche.

java.lang.String ist nicht vom Typ java.lang.Class

java.lang.String.getClass() vom Typ java.lang.Class

Answer 5

Interessant.

In Objective-C hat Klassenname zwei Rollen, als Datentyp und als Klassenobjekt. Als Datentypnamen, können Sie tun Dinge wie: nur als Nachrichtenempfänger

MyClass *anObject; 

als Klassenobjekt kann der Klassenname für das Klassenobjekt stehen. Und das ist, warum Sie

... isKindOfClass:[MyClass class] ... 

jedoch verwenden, ich glaube nicht, das ist die Antwort, die Ihren Bedarf befriedigen zu können. Für mich lautet die Antwort: "Ja, was du willst, ist plausibel. Aber die Spezifikation sagt den anderen Weg".

Referenz: The Objective-C Programming Language Page 32, section: "Class Names in Source Code".

Answer 6

Ich denke, dass MyClass eigentlich eine Meta-Klasse ist. Sie senden ihm die Klassennachricht, um die tatsächliche Klasse (vom Typ Klasse) zu erhalten.

Answer 7

@John und @ryanprayogo - Sie sind beide grundlegend falsch. MyClass ist eine Klasse, die auch ein Objekt ist, aber nicht von NSObject erbt. Objective-C ist auf diese Weise irgendwie komisch, aber es ist wirklich brillant, wenn es vollständig erklärt wird (siehe here). Die Antwort hier ist jedoch, wie @ Yehnan sagte, dass ein Klassenname entweder ein Typname für Deklaratoren und Umwandlungen sein kann, oder als ein Empfänger für Nachrichten. Die Implementierung von [MyClass class] gibt self zurück (was innerhalb der Methode MyClass ist).Auch wie @ Yehnan sagte, könnte die Sprache unterstützen es als Argument übergeben, obwohl es einfach nicht.

Answer 8

@ Yehnan fängt es gut ein, aber ich werde ein wenig darauf erweitern. Ja, der Compiler könnte so modifiziert werden, dass er automatisch eine Klassenkennung in die entsprechende Class an Stellen umwandelt, an denen es ein Argument ist, und nicht nur dann, wenn es das Ziel einer Nachricht ist. Aber es gibt keine große Nachfrage nach dieser zusätzlichen Komplexität im Compiler (übersetzt: langsamere, schwerer zu erkennende Codierungsfehler). Du solltest Dinge, die oft Class zurückgeben, nicht aufrufen. Wenn dies der Fall ist, ist das Objektmodell fehlerhaft. Klassenprüfung sollte der letzte, verzweifelte Ansatz sein, nachdem alles andere fehlgeschlagen ist (vor allem korrekte Eingabe und dann respondsToSelector:). Für diese Art von seltenen Ereignissen ist es nicht sinnvoll, den Compiler auf diese Weise zu komplizieren.