SEL: Methodenname sucht Methodenname?

[frauenPower]

Beschäftige mich gerade mit den Grundlagen und in diesem Zusammenhang mit Polymorphismus.
Methodennamen werden nach meinem Verständnis auch "Selektor" genannt und haben den Datentyp "SEL". Der Autor schreibt ja auch: "Aus diesem Grund gibt es in Objective-C für Methodennamen, auch Selektor genannt, den Datentyp SEL [...]."
Für einen Selektor kann es verschiedene Implementierungen geben.

In meinem Buch steht nun zu lesen:
"Für die Methode "

compare:options

" bekommt man den Selektor zum Beispiel durch folgende Anweisung:

SEL methodSelector = @selector(compare:options:);

Völliger Schwachsinn in meinen Augen:
" Der Namen der Methode setzt sich aus allen Einzelstücken inklusive der Doppelpunkte zusammen:
"

compare:options:

"!"

Wenn ein Selektor ein Methodenname ist und "

compare:options:

" ein Methodennamen ist, wieso soll ich mir dann für einen Methodennamen einen Methodennamen holen?

Auch hier zeigt sich: Ein wissender Mensch ist eine didaktische Null und redet nur Unsinn.

Kann mir da mal jemand sagen, was Sache ist?

Danke und liebe Grüße Karin, die jetzt erstmal zur Schoki greift

 

[below]

1) Es wäre gut, wenn Du sagen würdest, welches Buch das ist. Dann kann ich entweder mal Nachsehen, oder der Autor selbst ist vielleicht sogar im Forum angemeldet.

2) Ich habe leider Deine Frage nicht verstanden

Wichtig zu beachten ist, dass es in Objective-C das Konzept der "Nachrichten" gibt. Einem Objekt wird eine Nachricht gesendet, und es reagiert darauf mit dem Aufruf einer Methode.

Also, in C++ wird direkt "compareWithOptions()" aufgerufen. In Objective-C, also wenn man ganz genau nachsieht, wird erstmal "objc_msgSend()" aufgerufen. Das sendet einem Objekt eine Nachricht, und das Objekt kann dann kucken, was es damit macht.

Allerdings bin ich auch jemand, der an dieser Stelle "Mut zur Lücke" empfiehlt, falls Dein Thema jetzt nicht gerade "Die Objective-C Runtime" als Diplomarbeit ist. Wenn Du "einfach nur mal programmieren" willst, dann gibt es später immer noch genug Gelegenheit, sich das mit den Selektoren, Methoden, Messages und Implementierungen genauer anzusehen.

Also Antworte ich für den Moment: "42. Wie genau war die Frage?"

Alex

 

[frauenPower]

@below
Danke für Deine Worte. Das mit den Nachrichten habe ich verstanden.

Für mich ist ein Selektor zum gegenwärtigen Zeitpunkt überflüssig, nicht zu gebrauchen und ohne Wert.
Ein Selektor macht keinen Sinn, da er eine Referenz auf eine Methode ist, die sowieso da ist.

id str = @"Hello World";
if ([str compare:@"hello World" options: NSCaseInsensitiveSearch] == 0) {
	NSLog(@"Die Zeichenketten sind bis auf Groß/Kleinschreibung gleich");
}

Funktioniert. Für was also ein Selektor?

Den Methodennamen

compare:options:

kann ich hinsenden, wo es halt passt.
Was hole ich mir denn dann mit dieser Zeile:

SEL methodSelector = @selector(compare:options:)

und wofür ist es gut?

Ich folge derzeit dem Buch: S. Meyer, T. Wichers: Objective-C 2.0 und bin auf Seite 43.

Im übrigen schreibt Holger Frank: iPhone 4 - & iPad-Programmierung auf Seite 58:

Selektoren sind die Repräsentanz einer Methode zur Laufzeit. Sie besteht zur Laufzeit nicht aus dem Methodennamen, sondern aus einem eindeutigen Wert - also einer Referenz auf eine Methode. Das Laufzeitsystem stellt dabei sicher, dass die Selektoren eindeutig sind und Methoden mit dem gleichen Namen auch tatsächlich den gleichen Selektor haben.

Aha
Die Herren Meyer und Wichers schreiben, dass ein Methodenname auch Selektor genannt wird und jetzt sollen Methoden mit dem gleichen Namen auch tatsächlich den gleichen Selektor haben?

Wenn Methode = Selektor, dann ist das halt so. Da muss nichts sichergestellt werden.

Grude in meinen Augen.

Mal weiter stöbern
Karin

 

[norbi]

Die Obj-C Runtime cached die Selektoren, um darauf schneller zugreifen zu können. Mit dem Selektor holst Du Dir den "echten" Methodenaufruf der Obj-C Runtime, sozusagen. compareptions: ist "nur" der Name der Methode.

Versuch' mal performSelector: mit einem NSString @"compareptions:". Das wird nicht gehen, es geht nur mit dem Selektor von der Methode @"compareptions:".
Da liegt der Unterschied.

No.

 

[frauenPower]

So, mal weiter geforscht und nun schaue ich mir mal die Sache mit dem "Selektor" bei Klaus M. Rodewig: Objective-C und Cocoa auf der Seite 108 an:

Der Selector ist dabei die Implementierung jener Methode, die aufgerufen wurde.

Und ein paar Zeilen weiter unten:

Ein Selector bezieht sich immer auf den Methodennamen, nicht auf die Implementierung einer Methode.

wow, dass lasse ich dann mal so stehen.

Schmunzelnde Grüße
Karin

 

[frauenPower]

@norbi
Das ist mal ein Ansatz. Muss aber weiter nach der Funktion und damit dem Sinn eines Selektors suchen.
Die bisher gefundene Literatur ist da recht seltsam. Herr Negm-Awad äußert sich laut Index Band 1 eher gar nicht zum Thema.

Band 2 ist auch keine Offenbarung:

SEL bezeichnet den Selektor einer Nachricht. Hierbei handelt es sich sich vereinfachend gesagt um den Namen einer Methode/Nachricht mit allen Parameterbeschreibungen.

Da werfe ich doch Anfängerfrech

compare:options:

ist bereits der Name einer Nachricht entgegen.

Mal weiter stöbern, ich nehme nichts hin. Ich will es wissen!

Liebe Grüße
Karin

 

[below]

Prima. Weder Meyer, Wichers noch Frank gehört zu meinen Freunden. Wir müssen uns also nicht zurücknehmen

ALSO, den Absatz von Holger Frank verstehe ich nur wegen Vorwissen (also ich weiss, was er eigentlich sagen will). Das musst Du nicht verstehen

Zweitens: Es geht hier hauptsächlich um Hintergrundwissen. [object compare:foo options:bar] funktioniert, wunderbar, toll.

Warum braucht man dann Selektoren? Ich möchte das jetzt nicht "Spezialfälle" nennen, aber es sind jetzt nicht so die Dinge, die Dir jeden Tag über den Weg laufen.
Am häufigsten sicher, wenn Du eine Methode zeitversetzt ausführen willst. Da willst Du einem Objekt ja irgendwie mitteilen, was das sein soll. Also "performSelector:afterDelay:". Da stopfst Du einen Selektor rein.

Und besonders bevor es Blocks gab konnte man mit Selektoren lustige Dinge machen. In ein "sort" kannst Du einen Vergleichsselektor reinpacken, um unterschiedliche Sortierverhalten zu erreichen (ich nehme an, das ist das Beispiel, das Du hast).
Heute würde man sowas mit einem Block machen.

Schliesslich ist Objective-C ja sehr dynamisch. Man kann also sogar zur Laufzeit aus einem beliebigen String ("cooleMethode") einen Selektor machen, und dann mal kucken, ob ein Objekt damit was anfangen kann. Umgekehrt kann dieses Objekt dann, zur Laufzeit entscheiden, auf diesen Selektor zu reagieren.

Irgendwie klarer geworden?

Alex

 

[frauenPower]

@below
Danke Dir. Ein wenig lichtet sich der Schleier.

Vielleicht magst Du mir, wenn Du möchtest, bei Buck, Yacktman: Cocoa Design Patterns und der Seite 136 kurz folgen:

Objekte haben Methoden. Methoden sind Operationen, die das Objekt ausführen kann. [...]Verschiedene Objekte können gleichnamige Methoden haben, die unterschiedliche Operationen ausführen [...].

Absolut verständlich.

Und der nächste Punkt:

Eine Message fordert ein Objekt auf, eine Operation auszuführen. Das Objekt leitet aus der Message die entsprechende Methode ab. Dieselbe Message kann an verschiedene Objekte gesendet werden. Die Ergebnisse hängen von der Implementierung im Empfänger ab.

Einwandfrei verständlich.

compare:options:

kann mit den entsprechenden Parametern an unterschiedliche Objekte gesendet werden und je nach Implementierung ist das Ergebnis ein anderes.

Und jetzt kommt der "überflüssige" Punkt:

Ein Selektor identifiziert die Messages, die an ein Objekt gesendet werden[...]

wofür ist das gut

und das Objekt, was die Message empfängt, wählt mit dem Selektor die aufzurufende Methode aus [...]

Das hat das Objekt doch schon beim 2. Punkt machen können.

Sehe nur ich das so, dass Punkt 3 überflüssig ist? Nachricht wird gesendet, Ergebnis. Selektor identifiziert etwas, was schon funktioniert und das Objekt wählt nun die Methode aus, die unter 2 mit senden von

compare:options:

bereits erledigt werden könnte.

Oops, da muss man/frau erstmal dahinter kommen.

Grübelnde Grüße
Karin

 

[iCode]

Was hole ich mir denn dann mit dieser Zeile:

SEL methodSelector = @selector(compare:options:)

Du hältst mit der Variablen nun einen Selector.

und wofür ist es gut?

Wenn als Parameter irgendwo ein Selector erwartet wird, kannst Du diese Variable übergeben.

Beispiel: Ein Objekt vom Typ NSThread erwartet zur Initialisierung (siehe unten) einen Selector. Beim zweiten Parameter kannst Du nun die Variable methodSelector übergeben.

- (id)initWithTarget:(id)target selector:(SEL)selector object:(id)argument

Doku dazu: initWithTarget:selectorbject:

Wenn Methode = Selektor, dann ist das halt so. Da muss nichts sichergestellt werden.

Methode ist (faktisch) nicht gleich Selektor. Aber es wird im Sprachgebrauch meistens gleich verwendet. Das ist wie bei einem Buch. Der Selektor ist quasi wie der Titel eines Buches. Der Titel ist nicht das Buch selbst.

 

[frauenPower]

@icode und @below
so komme ich der Sache schon näher und kann weitermachen.

Wird sofort in mein Exzerpt eingebaut!

Danke Euch beiden
Karin

 

[frauenPower]

By the way: Was macht den NSThread mit "compareptions:"?

Grübel
Karin

 

[iCode]

Einen neuen Thread aufsetzen.

 

[frauenPower]

@iCode
dann muss ich passen. Was "compareptions:" nun mit einem Thread aufsetzen zu tun hat, kann sich einem Newbie nicht erschließen. Und hat auch keine Logik.

Da passe ich. Und höre auch an dieser Stelle erstmal auf. Das tut ja weh

Liebe Grüße
Karin

 

[cropfaktor]

Also, ein Objekt braucht einen Selektor, der nichts anderes ist, als eine Referenz auf eine Methode, wie beispielsweise compareptions:
Während wiederrum ein anderes Objekt sich einfach mit compareptions: begnügt.

Ist doch logisch Karin: Keine Logik!

Nimms einfach hin

Weiter so, Karin

 

[frauenPower]

Nee, nee cropfaktor

So einfach mache ich es mir nicht. Ich denke halt, dass so manches allgemein nicht verstanden wird und einfach nur so benutzt wird. Dann stellt sich oft die Frage nach dem "warum" nicht.

Beispiel: Klassen sind in einem Buch eine Sammlung von Objekten und in einem anderen sind Klassen einfach nur Objekte.

Da ich aber weiß, dass meine Kids genau diese Fragen stellen werden, versuche ich diese zu ergründen. Und die sind hartnäckig.

Fazit für heute: Selbst die Guru-Literatur kocht nur mit Wasser und wenn selbst below:

ALSO, den Absatz von Holger Frank verstehe ich nur wegen Vorwissen (also ich weiss, was er eigentlich sagen will). Das musst Du nicht verstehen

zu solchen Statements kommt, werde ich immer vorsichtiger.

Hingenommen wird nichts.

Liebe Grüße
Karin

 

[frauenPower]

Bei aller Ernsthaftigkeit, ich bin nach wie vor am Selektor dran, habe ich mir mal die Erklärung von den "0X02100"-Mannen zum Thema in der Folge 31 ab 12:06 angesehen und gehe da mal aus Lehrersicht ran:
solch ein Gestammel signalisiert: Keine Ahnung.

Nur so am Rande. Ich werde es rausbekommen und hier posten. Aber auch in den Links bei Google wird im Prinzip Null erklärt und nur gestammelt und alle wissens, oder doch nicht

so, jetzt gibt es Fußball und die Damen wissen wenigstens, was sie tun.

Jawohl
Liebe Grüße
Karin

 

[norbi]

Klassen sind in einem Buch eine Sammlung von Objekten und in einem anderen sind Klassen einfach nur Objekte.

In Cocoa gibt's halt zwei Sorten von Objekten:
1. Instanzen einer Klasse
2. Die Klassen selbst sind auch Objekte

No.

 

[iCode]

Was "compareptions:" nun mit einem Thread aufsetzen zu tun hat, kann sich einem Newbie nicht erschließen. Und hat auch keine Logik.

Es ging im Beispiel auch nur darum zu zeigen, was Du mit dem von Dir vorher definierten Selector machen kannst: Als Parameter verwenden.



Ein Beispiel, dass sich vielleicht schneller erschliesst wäre respondsToSelector:. Den kennt jedes Objekt. - Doku: respondsToSelector:

- (BOOL)respondsToSelector:(SEL)aSelector

Damit kannst Du ein Objekt fragen, ob es was mit dem übergegebenen Selector anfangen kann, und es gibt Dir YES oder NO zurück. - Das ist bspw. nützlich, wenn Deine Anwendung auf einem älteren System mit unterschiedlichen Eigenschaften (z.B. Notifications) laufen soll. Oder auf verschiedenen Geräten (Mac/iPhone/iPod/iPad) mit verschiedenen Ausstattungsmerkmalen (Micro, GPS, Lagesensor, etc.) läuft.



Besser noch ein Beispiel. Sehr nützlich ist makeObjectsPerformSelector:, welches NSSet und NSArray kennen. - Doku: makeObjectsPerformSelector:

- (void)makeObjectsPerformSelector:(SEL)aSelector

Ein Set enthält einen Haufen verschiedener Objekte. Schickst Du diesem Set die Nachricht mit dem Selektor als Parameter, so bekommen alle darin enthaltenen Objekte den Selektor als Nachricht geschickt. - Vergleichbar wie wenn man dem Rektor/Hausmeister eine Durchsage machen lässt.

 

[frauenPower]

In Cocoa gibt's halt zwei Sorten von Objekten:
1. Instanzen einer Klasse
2. Die Klassen selbst sind auch Objekte

No.

Klar doch. Nur wird es manchmal gruselig erklärt und wenn dann die berühmt falschen "Ich baue ein Auto"-Beispiele kommen, um irgendwie alles so zu verbiegen, dass die unwahre Behauptung "Objective-C" könnte die Wirklichkeit abbilden YES wird, reicht es mir mit dem Verständnis.

Liebe Grüße
Karin

 

[frauenPower]

@iCode
Danke Dir. Wird gedanklich gleich aufgearbeitet.

Liebe Grüße
Karin