SEL: Methodenname sucht Methodenname?

[frauenPower]

Mal bei:
http://nb.wikipedikia.org/wiki/Objective-C
nachsehen.

Eine Methode mit einem bestimmten Namen (Selector) kann von Objekten jeder Klasse ausgeführt werden, die sie implementieren. Es ist nicht erforderlich, dass der Aufrufer die Klasse kennt oder die Methoden bereits in einer Basisklasse – wenn auch nur virtuell – definiert worden sind.

Und dann:

interface KlasseA : NSObject {
    …
}
- (void) ersteMethode;    // Eine Methode in der Subklasse
- (void) zweiteMethode;   // Weitere Methode
@end
 
 
@interface KlasseB : NSObject {
    …
} 
- (void) zweiteMethode;   // Es wird nur die zweite Methode implementiert.
@end
 
// Irgendeine Instanz der Klasse A oder B.
id anObject = …
[anObject zweiteMethode];

Bin ich jetzt pingelig oder was? Er "implementiert" doch gar nicht. Er definiert im Headerfile die Methoden.

Genau das meine ich: Wieder nichts verstanden und zudem noch schlecht erklärt.

ist das eigentlich eine hochoffizielle Seite?

Schauder
Karin

 

[iCode]

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.

Mir ist bei meinem obigen Beitragm aber jetzt eben auch wieder bewusst geworden wie schwer (mir) das fällt, es nur mit geschriebenen Worten zu erklären.

Deshalb habe ich ja kein Buch darüber geschrieben, obwohl ich zweimal gefragt wurde.

 

[frauenPower]

@iCode
Mist, genau danach wollte ich fragen, bei all Deinem profunden Fachwissen.


Dann mal ran, die Methode "kapiertsDummy" stellt die Klasse "Karin" Dir über alle Grenzen zur Verfügung

Liebe Grüße
Karin

 

[iCode]

@iCode
Mist, genau danach wollte ich fragen, bei all Deinem profunden Fachwissen.

Ich feile zu lange an der möglichst präzisen Formulierung. Und das Ergebnis gefällt mir dann meist sprachlich nicht. Den Beitrag da oben habe ich bestimmt 8 mal ergänzt und editiert. ...Ein Teufelskreis.

 

[frauenPower]

so und damit an dieser Stelle auch die Info zu meinem Programm, was ich für meine Kids schreibe:
Lern-Lexikon.
Man kann beliebige Fachbegriffe auf dem iPad mit der zugehörigen Erklärung anlegen, alphabetisch sortieren und nach "Rubriken" einordnen.
Darüberhinaus kann natürlich in allen Einträgen frei nach Suchworten oder Kombinationen gesucht werden.
Später soll es die Möglichkeit geben, verschiedene Lexikas anlegen zu können und diverse Erweiterung.

So kann dann Hans sich ein kleines Lexikon zu seiner "Matchboxsammlung" anlegen, Maria sich ein Englischlexikon anlegen und die Karin eben ein Stichwortlexikon zu Objective-C.

Nicht all zu schwer und gut zu erweitern, so dass die Kids dann diverse Prinzipien "Suchalgorithmen" oder auch "Speichertechniken" kennenlernen können.

Insofern, muss ich "Selektor" mit einfachen Worten erklären können, damit der Begriff in mein Hirn Eingang findet und in das im entstehen begriffene Lexikon.

Liebe Grüße
Karin

 

[frauenPower]

ch feile zu lange an der möglichst präzisen Formulierung. Und das Ergebnis gefällt mir dann meist sprachlich nicht. Den Beitrag da oben habe ich bestimmt 8 mal ergänzt und editiert. ...Ein Teufelskreis.

Nee, alles eine Frage des Lektors.

Sowas ist halt auch eine Zeitfrage denke ich.

Aber Du siehst: Es fehlt in der Tat an einem Grundlagenbuch, was den Newbie eben packt und mitnimmt. Viele schimpfen sich zwar Grundlagenbücher, aber verstehen es nicht, komplexe Sachverhalte in verständliche Worte zu formulieren.

Liebe Grüße
Karin

 

[iCode]

Nee, alles eine Frage des Lektors.

Sowas ist halt auch eine Zeitfrage denke ich.

Definitiv. Habe ich bei einem Freund mit bekommen, zu dessen Buch ich ein Kapitel beigetragen habe. Der hatte 16 Monate kein Familienleben mehr.

Aber Du siehst: Es fehlt in der Tat an einem Grundlagenbuch, was den Newbie eben packt und mitnimmt. Viele schimpfen sich zwar Grundlagenbücher, aber verstehen es nicht, komplexe Sachverhalte in verständliche Worte zu formulieren.

Das Problem ist imho, dass die verwendeten Konzepte schon fortgeschritten und sehr abstrakt sind. Das dann einfach und verständlich zu erklären ist schon eine Herkulesaufgabe, insbesondere wenn u.a. der Background fehlt.

 

[frauenPower]

Das Problem ist imho, dass die verwendeten Konzepte schon fortgeschritten und sehr abstrakt sind. Das dann einfach und verständlich zu erklären ist schon eine Herkulesaufgabe, insbesondere wenn u.a. der Background fehlt.

Gebe ich Dir Recht. Aber selbst wenn frau mit viel Fleiß und wenig Talent an die Sache rangeht, ist es nicht leicht den Background zu erwerben. Bin seit geschlagenen 7 Stunden am Selektor und alle tun so, als wäre es das normalste von der Welt und nirgendwo wird es fundamental erklärt.
Damit kann man das und das machen ist keine Erklärung.

Aber ich gebe nicht auf und hoffe, dass Du Dich doch mal zu so einem lohnenswerten Projekt aufraffen kannst.

Purer Egoismus, ich weiß.

Liebe Grüße
Karin

 

[iCode]

Gebe ich Dir Recht. Aber selbst wenn frau mit viel Fleiß und wenig Talent an die Sache rangeht, ist es nicht leicht den Background zu erwerben. Bin seit geschlagenen 7 Stunden am Selektor und alle tun so, als wäre es das normalste von der Welt und nirgendwo wird es fundamental erklärt.

Es ist tatsächlich so simpel, wie meine Buch-Metapher vorhin. Vielleicht löst Du Dich einfach mal davon, und lässt das Thema einen Moment liegen.

Damit kann man das und das machen ist keine Erklärung.

Der Witz ist: Jeder der/die im Interface Builder Connections zwischen den Elementen zieht macht davon gebrauch. Wenn man dort die auszuführende Methode (Action) festlegt, setzt man in Wirklichkeit eigentlich nur den entsprechenden Selector.

Aber ich gebe nicht auf und hoffe, dass Du Dich doch mal zu so einem lohnenswerten Projekt aufraffen kannst.

Seit etwa 25 Jahren schreibe ich jetzt professionell Software. Ich habe manchmal eher das Bedürfnis mal was ganz anderes zu machen. - Schafe züchten. Bier brauen. Welt umsegeln.

 

[yunharla]

Selektoren sind wie Herr below schon gesagt nichts weiter als Nachrichten die den Empfänger auffordern eine Methode aufzurufen. Ein Vorteil dabei ist das der Empfänger dem Sender im Vorfeld mitteilen kann wie die Nachricht in etwa aufzubauen ist wodurch man kein gemeinsames Interface für verschiedene Empfänger braucht.Nachteile gegenüber Interfaces oder Blöcken sind z.B. schlechtere Performance und größere "Unsicherheit".

 

[frauenPower]

@yunharia
Danke Dir. Werde ich mir heute Abend noch zu Gemüte führen.

@iCode
Bier brauen ist OK. Her damit.

So, und jetzt wird Fußball geschaut und dann geht es weiter.

Danke an Euch beiden
Karin

 

[frauenPower]

Weniger ist mehr:

    //eine Variable definieren und initialisieren
    NSString *meinString = @"HIER IST KARIN";
    
    //Alles in Kleinschreibung
    NSLog(@"Aus groß wird klein: %@", [meinString lowercaseString]);

Und nun mit "selector":

   //eine Variable definieren und initialisieren
    NSString *meinString = @"HIER IST KARIN";
    
    //keine Ahnung, aber es funktioniert
    SEL dooferSelector = @selector(lowercaseString);
    
    //Eine Variable zum Aufnehmen des Booleschen Werts
    NSString *kleinGeschrieben = (([meinString respondsToSelector:dooferSelector]) ? @"YES" : @"NO");
    
    //Ausgabe, ob lowercaseString möglich ist
    NSLog (@"Geht denn lowercaseString: %@", kleinGeschrieben);
    
    
    if ([meinString respondsToSelector:dooferSelector]) //(kleinGeschrieben == @"YES")
        NSLog(@"alles klein geschrieben: %@"  , [meinString lowercaseString]);

Wow. In diesem Falle "no selector" für die Karin

Liebe Grüße
Karin

 

[below]

Ich bin mir immer noch nicht sicher, was im Detail Dein Verständnisproblem ist, aber ich glaube, der wichtigste Satz ist dieser hier:

Methode ist (faktisch) nicht gleich Selektor. Aber es wird im Sprachgebrauch meistens gleich verwendet.

In C++ bedeutet theObject->doThatThing(), dass Du die Methode doThatThing des Objekts aufrufst. Wirklich die Methode "doThatThing", ziemlich direkt und unvermittelt.

In Objective-C läuft das bei [theObject doThatThing] etwas anders ab: Du schickst hier dem Objekt eine Nachricht. Das Objekt bekommt dann diese Nachricht. Und dann stellt sich das Objekt die Frage, wie es auf diese Nachricht reagiert.

In 99% aller Fälle passiert dann "Oh, hey, schick, ich hab ja auch eine Methode, die genau so heisst. Cool, nehmen wir die doch!"

Das ist aber kein zwingender Zusammenhang. Ein Objekt könnte auch sagen: "Hrm, eine Methode doThatThing hab ich nicht. Aber statt dessen könnte ich die nehmen, die doThatBustaRhymesDance heisst".

Eine Variable vom Typ SEL enthält einfach den Namen der Nachricht.

Wird es etwas klarer?

Alex

 

[frauenPower]

@below
Danke Dir für Deine Geduld. Irgendwo hakt es bei mir oder setzt auch aus, je nachdem...

In C++ bedeutet theObject->doThatThing(), dass Du die Methode doThatThing des Objekts aufrufst. Wirklich die Methode "doThatThing", ziemlich direkt und unvermittelt.

In Objective-C läuft das bei [theObject doThatThing] etwas anders ab: Du schickst hier dem Objekt eine Nachricht. Das Objekt bekommt dann diese Nachricht. Und dann stellt sich das Objekt die Frage, wie es auf diese Nachricht reagiert.

In 99% aller Fälle passiert dann "Oh, hey, schick, ich hab ja auch eine Methode, die genau so heisst. Cool, nehmen wir die doch!"

Voll verstanden. Davon spreche ich ja die ganze Zeit.

Das ist aber kein zwingender Zusammenhang. Ein Objekt könnte auch sagen: "Hrm, eine Methode doThatThing hab ich nicht. Aber statt dessen könnte ich die nehmen, die doThatBustaRhymesDance heisst".

Doch der Zusammenhang ist "zwingend". Wenn ich als Programmierer einem Objekt eine Nachricht schicke, dann weiß ich, dass sie existiert. Es gibt keinen Grund, warum ich einfach so ins "blaue" eine Nachricht schicken sollte.
Ich muss doch wissen, was ich programmiere

Und dass ein Objekt mit der Nachricht antwortet: "Hrm, eine Methode doThatThing hab ich nicht. Aber statt dessen könnte ich die nehmen, die doThatBustaRhymesDance heisst" ist gar nicht möglich. Das glaube ich nicht. Ein Objekt hat beispielsweise 35 Methoden. Woher soll es denn wissen, welche Methode es nun als mögliche Alternative zur Verfügung stellt.

So beliebig ist dann Programmierung doch hoffentlich nicht wirklich

Liebe Grüße und Danke Dir
Karin

P.S.:

Eine Variable vom Typ SEL enthält einfach den Namen der Nachricht.

vollkommen klar.

 

[below]

Doch der Zusammenhang ist "zwingend". Wenn ich als Programmierer einem Objekt eine Nachricht schicke, dann weiß ich, dass sie existiert. Es gibt keinen Grund, warum ich einfach so ins "blaue" eine Nachricht schicken sollte.
Ich muss doch wissen, was ich programmiere

Aha! Da haben wir das Problem!

Und dass ein Objekt mit der Nachricht antwortet: "Hrm, eine Methode doThatThing hab ich nicht. Aber statt dessen könnte ich die nehmen, die doThatBustaRhymesDance heisst" ist gar nicht möglich. Das glaube ich nicht. Ein Objekt hat beispielsweise 35 Methoden. Woher soll es denn wissen, welche Methode es nun als mögliche Alternative zur Verfügung stellt.

So beliebig ist dann Programmierung doch hoffentlich nicht wirklich

Nein, natürlich ist das nicht beliebig. Aber der Zusammenhang ist nicht zwingend. Bei C++ ist er zwingend, nicht bei Objektive-C. Denk dynamisch, denk "zur Laufzeit". Programmier ein bisschen Smalltalk oder Common Lisp.

Die nicht-akademischen Anwendungen für eine Auflösung dieser Beziehung sind sicherlich nicht sehr vielfältig. Aber stell Dir folgendes vor:

Du hast ein Objekt, dass als Parameter nur ein WSDL (WebServiceDescriptionLanguage) File bekommt. Es kann diese Datei dann auswerten, und sich zur Laufzeit entscheiden, auf entsprechende Nachrichten mit Parametern zu reagieren. Andere Objekte könnten diese Methoden dann einem Benutzer in einem UI anzeigen, und entsprechende Selektoren aufrufen.

Das hat mit beliebig nichts zu tun, hier ist es ein Beispiel für Parametrisierung.

Wieder ein Stück klarer?

Alex

 

[frauenPower]

@below

Du bist echt nett. Danke Dir schon jetzt.

Ja, den casus cnactus hast Du gefunden.

C++ ist mir halt näher und wahrscheinlich werde ich auch so programmieren. Schon der Begriff zur "Laufzeit" erschreckt mich. Mein Programm läuft = Laufzeit. Wofür zur Laufzeit wissen die Götter.

Du hast ein Objekt, dass als Parameter nur ein WSDL (WebServiceDescriptionLanguage) File bekommt. Es kann diese Datei dann auswerten, und sich zur Laufzeit entscheiden, auf entsprechende Nachrichten mit Parametern zu reagieren. Andere Objekte könnten diese Methoden dann einem Benutzer in einem UI anzeigen, und entsprechende Selektoren aufrufen.

Ein Objekt bekommt als Parameter ein File. Und dann noch Nachrichten, auf das es mit Parametern reagiert. Und andere Objekte können diese Methoden dann einem Benutzer Anzeigen und entsprechende Selektoren aufrufen.

Ähhh, ich passe dann mal schnell an dieser Stelle.

Lieben Dank trotzdem
Karin

 

[below]

Nur kurz: C++ macht Entscheidungen zur Kompilezeit, also, wenn das Programm gebaut wird. Objective-C trifft im Gegensatz dazu ziemlich alle Entscheidungen zur Laufzeit, also erst wenn das Programm läuft.

Das kann Dir im normalen Objective-C Entwicklerleben fast ziemlich egal sein. Es ist aber der Grund, warum "Object may not respond to selector" nur eine Warnung, kein Fehler ist.

Alex

 

[frauenPower]

Puh, da bin ich beruhigt. Hatte schon arge Bedenken.

Ich nehme das mit dem Selector einfach mal so hin und habe mir schon eine Wiedervorlage eingerichtet. Das Thema wird verfolgt, bis auch ich es ins Hirn bekomme.

Liebe Grüße
Karin

 

[Dalgliesh]

Also vorweg: Ich habe null Ahnung von Objective C. Aber ich habe diese Diskussion hier verfolgt und nichts verstanden. Dann habe ich die Dokumentation gelesen. Soll manchmal helfen. Ist es nicht einfach folgendermaßen?

Man kann eine Methode (oder Nachricht) über ihren Namen aufrufen.

Nun haben wir eine Situation, wo wir zwar die Nachricht kennen, aber nicht das Objekt, dem wir die Nachricht schicken möchten (zB weil das Objekt A, dem wir die Nachricht schicken möchten, von einem anderen Objekt B verwaltet wird). Im Beispiel könnten wir nun Objekt B sagen: "Bitte schicke Objekt A die Nachricht".

Eine Nachricht kann immer über ihren Namen identifiziert werden. Allerdings ist das manchmal ein bißchen langsam. Denn "intern" werden Nachrichten nicht über einen Namen identifiziert, sondern über einen Selektor (was einfach eine computerfreundlichere Darstellung des Namens ist). Aber Namen und Selektoren entsprechen sich 1 zu 1.

Wenn es im obigen Beispiel nun nicht nur ein Objekt A gibt, dem die Nachricht geschickt werden soll, sondern 100, und wenn ich die Nachricht über ihren Namen identifiziere, dann muß der Name 100x in die interne Darstellung umgewandelt werden. Das kostet Zeit und ist überflüssig.

Deswegen wandle ich den Namen "von Hand" um, d.h. ich ermittle aus dem Namen den zugehörigen Selektor. Und dann sage ich Objekt B, es soll allen 100 Objekten die durch den Selektor dargestellte Nachricht schicken. Das Ergebnis ist genau gleich, als würde ich mit dem Nachrichtennamen arbeiten, aber halt schneller.

Ist das jetzt komplett falsch?

 

[below]

Nur mal so als kurzes Stück Code zur Nacht:

#import <Foundation/Foundation.h>
#import <objc/objc-class.h>

// To pacify the compiler
void handlerImp (id self, SEL _cmd);

void handlerImp (id self, SEL _cmd) {
    NSString *selector = NSStringFromSelector (_cmd);
    NSLog (@"Bo Selecta: %@", selector);
}

@interface DynamicClass : NSObject
+ (void) addNewThing:(NSString *)newName;
@end

@implementation DynamicClass
+ (void) addNewThing:(NSString *)newName {
    SEL selector = NSSelectorFromString (newName);
    class_addMethod (self, selector, (IMP)handlerImp, "v@:");
}
@end

int main (int argc, const char * argv[])
{
    NSAutoreleasePool *pool = [NSAutoreleasePool new];
    
    DynamicClass *dynamicObject = [[[DynamicClass alloc] init] autorelease];
    [DynamicClass addNewThing:@"hitIt"];
    [dynamicObject hitIt];
    
    [pool drain];
    return 0;
}

Alex