SEL: Methodenname sucht Methodenname?

rofl, nun überforder doch mal das arme Mädel net so :D
 
@yunharia
Diese Replik führt Dich aber nicht automatisch in den Olymp des Wissenden.

@Alex
hübsch

@Dalgliesh
Danke Dir. Mir fehlt jedoch das Wissen, um beurteilen zu können, ob das so stimmt. Die Dokumentation von Apple zu diesem Thema ist für einen Newbie nicht zu verstehen.
Dieser Teil stimmt schon semantisch nicht:
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".
Erst kennen wir das Objekt nicht und dann möchten wir dem Objekt, was wir nicht kennen eine Nachricht schicken. Geht gar nicht. Und wie ein Objekt ein anderes verwaltet, ist mir auch noch nicht untergekommen.
Dem Teil davor und danach kann ich logisch folgen, bin mir aber nicht sicher, ob der stimmt, weil mir da das Wissen zu fehlt.


Habe zumindest erfahren, dass es keiner erklären kann und das stimmt mich bedenklich. Es werden offensichtlich einige Sachen einfach so hingenommen und die wenigen, die den Durchblick haben, können es nicht verständlich erklären, so dass auch der Anfänger damit zurande kommt.
Dann heißt es Grundlagen. Man solle Grundlagen büffeln und kann es doch nicht, weil a) die Literatur genau von denen geschrieben wird, die nicht erklären können und b) man dann exakt dahin geschoben wird, dass man einfach nur noch hinnimmt und so tut, als wüsste man es.
:Pah: nicht mit mir.

Werde heute den kompletten Tag darauf verwenden, exakt dies zu ändern und Antwort auf die Fragen zu finden:
  1. Was ist ein Selector?
  2. Wofür setzt man diesen ein?
  3. Warum tut man das?
  4. Ein Beispiel dafür, was Sinn macht.

Antworten a la: Damit kann man... sind keine Erklärungen!

Sowas würde ich im Unterricht nicht eine Sekunde durchgehen lassen.

Liebe Grüße
Karin
 
Wir müssen hier unterscheiden: Grundlagen sind, wie Du eine Variable vom Typ SEL verwendest, um zum Beispiel eine Sortierung durchzuführen.
Frei nach dem Motto: "Ne Dampfmaschin, dat issne schwarze Kessel. Alles andere kriegen mer später".

Was GENAU, IM DETAIL ein Selector macht und tut und warum, sind meiner Ansicht nach alles andere als Grundlagen.

Die Dokumentation sagt: "In Objective-C, selector has two meanings. It can be used to refer simply to the name of a method when it’s used in a source-code message to an object."
Der Teil sollte Dir erstmal reichen. Also: Ein Selector ist nur ein anderer Weg, um den Namen einer andren Methode anzugeben. Und in einer Variable vom Typ SEL kann man das speichern. Wenn Du wolltest, könntest Du über all statt

[foo doThis:x withThat:y];

schreiben:

[foo performSelector:mad:selector(doThis:withThat:) withObject:x withObject:y].

Ist das selbe. Identisch. Vollkommen (naja, nicht ganz, aber das geht zu weit)... . Das erste sieht nur schicker aus.
Selectors werden dann verwendet, um die Namen von Selectoren zu übergeben. Das ist für Sort sinnvoll, für "performSelector:afterDelay", für Threads und einiges mehr.

"It also, though, refers to the unique identifier that replaces the name when the source code is compiled.". Das its erst einmal nicht so wichtig. Das macht ales der Compiler für Dich.
Wenn Du wirklich im Detail verstehen willst, was das heisst, musst Du Dich mit den Details der Objective-C Runtime beschäftigen. Das ist akademisch Spannend, aber nicht wirklich notwendig.

Deshalb kann Dir auch niemand vollständig erklären, was ein Selector ist, ohne dazu erst einmal Vorwissen über die Runtime aufzubauen.

Besser?

Alex
 
Und nun mit "selector":
Code:
   //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]);

Um das Beispiel komplett mit dem Selector durchzuziehen, hättest Du in der letzten Zeile "...performSelector:" benutzen können.


Erst kennen wir das Objekt nicht und dann möchten wir dem Objekt, was wir nicht kennen eine Nachricht schicken. Geht gar nicht. Und wie ein Objekt ein anderes verwaltet, ist mir auch noch nicht untergekommen.

In Objective-C geht das, und das wird auch genutzt.
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: below
In Objective-C geht das, und das wird auch genutzt.

Das liegt hat daran, dass Objektive-C seine Wurzeln im Objektsystem von Smalltalk hat. Da waren solche Spässe an der Tagesordnung.

Warum auch nicht, ich fand das immer sehr einleuchtend: Man schickt einfach mal einen Nachricht in den Raum "Hallo, ich will was drucken!" und wenn einer da ist, der's drucken kann, dann macht der das. Wenn nicht, dann halt nicht.

Alex
 
  • Gefällt mir
Reaktionen: iCode
Warum auch nicht, ich fand das immer sehr einleuchtend: Man schickt einfach mal einen Nachricht in den Raum "Hallo, ich will was drucken!" und wenn einer da ist, der's drucken kann, dann macht der das. Wenn nicht, dann halt nicht.

Gerade bei Collections gehört das zur Tagesordnung.
 
Ahh,

jetzt wird es klarer und ich sollte mich mit der Runtime beschäftigen. Werde ich auf jeden Fall auch tun, aber etwas später.

Ich habe mir auch die Apple-Doku angesehen und dieser Satz macht mir jetzt noch Kummer:
All methods with the same name have the same selector.
Alle Methoden mit dem gleichen Namen haben den gleichen Selektor.
Karin: "In der Klasse KarinEins habe ich eine Methode 'schuelerQuaelen'. In der Klasse KarinZwo habe ich ebenfalls eine Methode 'schuelerQuaelen'. Ein Selektor würde nun auf beide zugleich zeigen? Oops woher weiß dann das Programm, welche Methode ich denn nun gerne beim Aufruf verwenden möchte?"

Daaanke Euch Supergeduldigen
Karin
 
gelöscht
 
Zuletzt bearbeitet:
"In der Klasse KarinEins habe ich eine Methode 'schuelerQuaelen'. In der Klasse KarinZwo habe ich ebenfalls eine Methode 'schuelerQuaelen'. Ein Selektor würde nun auf beide zugleich zeigen? Oops woher weiß dann das Programm, welche Methode ich denn nun gerne beim Aufruf verwenden möchte?"

Weil ein Selector nur in Verbindung mit einem Target etwas aufruft! Ein Selector zeigt auf nichts, ein Selector ist nur eine andere Form für einen Namen

Das ist aber ganz normale OPP, und hat mir Selectors nichts zu tun:

Sei "eins" ein Objekt der Klasse eins, und "zwei" ein Objekt der Klasse KarinZwei
Code:
[eins schuelerQuaelen];
[zwei schuelerQuaelen];
Hier ist Dir doch klar, was aufgerufen wird, richtig?

Das ist äquivalent zu:
Code:
SEL quaelector = @selector(schuelerQuaelen);
[eins performSelector:quaelector];
[zwei performSelector:quaelector];

Klar?

Alex
 
Juchhuuu,

Danke Alex.

Werde ein Exzerpt für mein kleines Lexikon schreiben und dann verfügbar machen.

Was lernte ich außerdem: Geh nicht zu sehr in die Tiefen und mache es später.

Liebe Grüße
Karin
 
Naja was belows Code von Gestern anstellt ist nicht sooo schwer zu verstehen, die Frage ist nur ob man es auch verwenden kann oder will. Ehrlich gesagt ist mir bisher nur ein Fall begegnet wo ich so etwas tatsächlich gebraucht habe.(Stichwort: MIMD).

Ein einfaches Beispiel für die Verwendung von Selectoren wäre eine WebClient Klasse. Da unser Client möglichst vielseitig einsetzbar sein soll, müssen wir dafür sorgen das es ihm a) egal ist welches Objekt eine Antwort erhält und b) wieviele verschiedene Antworttypen das Empfängerobjekt verarbeiten soll. Daher übergeben wir an die Anfragemethode erst einmal die Objekt ID welche uns sagt an wem die Antwort gesendet wird und einen SEL für die Methode die den erwarteten Antworttypen bearbeiten soll.

Bei wenigen Antworttypen mag es zwar noch ohne Selector gehen , aber stell dir nun einmal vor du wolltest einen Datenbankeditor schreiben. Dort hast du schon einmal mindestens 5 verschiedene Antworttypen (Create ,Delete ,Exception ,Retrieve ,Update ) die dein Objekt erhalten kann. Hinzu kommen noch die Klassen für die einzelnen Felder und die Metadaten und schon bis du bei etwa 30 verschiedenen Klassen die deine ViewController verwalten sollen. Und wie du an folgenden Codebeispiel (welches nur für die Tabellen in einer Datenbank behandelt) erkennen kannst ist es einfach nur noch glatter Selbstmord das ganze über Vererbung zu gestalten...

Code:
		DBTABCONTROLLER.Instance.Clients[DBTABCONTROLLER.Instance.selectedtab ? 1 : 0].MetaEntities(SelectedTable, true, new ClientCallBackHandler(){

			@Override
			public void StartCallBack() {
				// TODO Auto-generated method stub
				DBTABCONTROLLER.Instance.LoadStart();
			}

			@Override
			public void EndCallBack(boolean success) {
				// TODO Auto-generated method stub
				
				if(success)
				{
					try{
						ExceptionResponse except = (ExceptionResponse) this.response;
						ab.setMessage(Html.fromHtml("<b><font color=#ff0000>" + except.Message));
						ab.setPositiveButton("ok", null);
						ab.show();
						success = false;
					}catch(Exception e)
					{
						MetadataEntitiesResponse resp = (MetadataEntitiesResponse) response;
						if(resp.Entities[0] != null)
						{
							Tab = resp.Entities[0];
							Field = DBTABCONTROLLER.Instance.Clients[DBTABCONTROLLER.Instance.selectedtab ? 1 : 0].DbEntryname;
							for(Property prop : Field.Properties)
							{
								boolean ignoreprop = false;
								for(AttributeMetaData Key : Tab.PrimaryKeys )
								{
									//primary keys should be generated automatically or only set once!!!!!
									if(Key.Name.contentEquals(prop.Name) && (Key.IsIdentity || !prop.IsNull))
									{
										if(!prop.IsNull)
											PrimKeys.add(prop);
										ignoreprop = true;
										break;
									}
								}
								if(!ignoreprop)
								{
									adapter.add(prop.Name);
								}
								else
								{
									adapter.add(prop.Name + ": " + prop.ToString());
								}
							}
							if(PrimKeys.size() == 0)
							{
								isCreateMode = true;
								for(final Property prop: Field.Properties)
								{
									PropsToUpdate.add(prop);
									Log.v(prop.ClassName, prop.ToString());
								}								
							}

						}
						
						
					}
                                      DBTABCONTROLLER.Instance.LoadStop();
				}
			}
		});
 
Zuletzt bearbeitet:
@Dalgliesh
Danke Dir. Mir fehlt jedoch das Wissen, um beurteilen zu können, ob das so stimmt. Die Dokumentation von Apple zu diesem Thema ist für einen Newbie nicht zu verstehen.
Dieser Teil stimmt schon semantisch nicht:

Erst kennen wir das Objekt nicht und dann möchten wir dem Objekt, was wir nicht kennen eine Nachricht schicken. Geht gar nicht. Und wie ein Objekt ein anderes verwaltet, ist mir auch noch nicht untergekommen.

Also sorry. Eine gewisse Offenheit gehört zum Lernen dazu. Für jemanden, der sich nicht auskennt, scheinst Du ziemlich genau zu wissen, was *nicht* stimmt. Nur soviel: Selbstverständlich kannst Du jemandem eine Nachricht schicken, den Du nicht kennst. Du klebst einen Zettel an Dein Auto "zu verkaufen für 5000€". Das ist eine Nachricht, und die potentiellen Leser kennst Du bis jetzt nicht.

Aber gut, viel Spaß und Erfolg beim Weiterlernen.
 
@Dalgliesh
Sorry, wollte Dir nicht auf die Füße treten. Habe nur beschrieben, wie es sehe und "Offenheit" ist da, sonst würde ich mir das in meinen Ferien nicht antun.

Und es ist für mich sehr schwer von einem Zettel an einem Auto auf das Programmieren zu abstrahieren oder Sätze wie

Warum auch nicht, ich fand das immer sehr einleuchtend: Man schickt einfach mal einen Nachricht in den Raum "Hallo, ich will was drucken!" und wenn einer da ist, der's drucken kann, dann macht der das. Wenn nicht, dann halt nicht.
hinzunehmen.

Ich habe ein wenig Pascal, minimal VBA und C++ drauf und weiß zu jedem Zeitpunkt was ich mache. Davon wegzukommen ist sehr, sehr schwer!

Also, bitte nicht böße sein und dickes Entschuldigung von mir
Karin
 
Tja Karin,

ich habe für meinen Teil, und ich habe es immerhin geschafft, eine kleine gut funktionierende Applikation hinzubekommen, die auch beruflich genutzt wird, das Fazit gezogen, dass ich zu doof, zu alt oder was weiss ich bin.
Es wird nicht gehen und ja ich nehme Dir vielleicht den Mut, was ich nicht glaube.

Nutze Deine Ferien und erfreue Dich an was anderem, aber ein Privatmann ohne Informatikstudium wird das nicht hinbekommen.

Überlege mal, wie viele Stunden Du mit dem Selector verbracht hast?

Nur mal so eingeworfen.

Toi, toi, toi
Andreas
 
  • Gefällt mir
Reaktionen: frauenPower
@yunharia
Danke für Deine hilfreiche Erklärung. Und ich würde mich hier nicht so stressen, wenn ich es nicht lernen wollte. Profis wie Euch ist das alles bekannt, ich betrete hier Neuland und orientiere mich und stelle Fragen. Also Danke an Deine Stelle!

@cropfaktor
Heftige Worte, die aber lieb gemeint sind. Ich kann nachvollziehen, was Du mir sagen willst.

Ich ziehe dass jetzt alles noch 300 Stunden durch. Ich bleibe jeden Tag 14 Stunden dran und dann entscheide ich. Habe ich am Schluss mehr Fragen als vorher und sehe Land: weitermachen.
Andernfalls schmeiße ich zum ersten mal das Handtuch. Für eine Mathelehrerin ziemlich traurig. Ich schiebs dann aufs Alter :D

Pack mas
Karin
 
Ich habe ein wenig Pascal, minimal VBA und C++ drauf und weiß zu jedem Zeitpunkt was ich mache. Davon wegzukommen ist sehr, sehr schwer!
Ich hatte damals einen sehr starken C-Hintergrund. Objective-C war für mich ein Kulturschock. :D

Andernfalls schmeiße ich zum ersten mal das Handtuch. Für eine Mathelehrerin ziemlich traurig. Ich schiebs dann aufs Alter.
Nein. Schmeiss den Balast weg. Das erleichtert das Verstehen immens.

P.S. Ich meine ebm schrieb bereits an anderer Stelle, dass C++ dieses dynamische Denken eher behindert.
 
Zuletzt bearbeitet:
Ich bin in meinem Alter und mit meiner bescheidenen Intelligenz auch schon bei verschiedenen Sachen ausgestiegen weil es zu kompliziert ist. Ist aber egal, ich will etwas machen und habe immer eine Lösung gefunden, auch wenn ich nicht ganz genau verstehe wie GENAU die Hintergründe sind.

Den Selektor verstehe ich auch nicht so in der Tiefe wie es Karin gern hätte, aber was ich verstehe reicht mir um ihn anwenden zu können. Darüber brauche ich nicht mehr als 5 Minuten nachzudenken, solange er das tut was ich will.

In meinem Programm dass ich grad zur Übung schreibe könnte ich einen Selektor einbauen (juckt mich auch gerade das zu tun).
Ich habe von GPS Gerät verschiedene Datensätze bekommen:
Code:
$GPRMC,191410,A,4735.5634,N,00739.3538,E,0.0,0.0,181102,0.4,E,A*19
$GPRMB,A,9.99,L,,Exit,4726.8323,N,00820.4822,E,29.212,107.2,,V,A*69
$GPGGA,191410,4735.5634,N,00739.3538,E,1,04,4.4,351.5,M,48.0,M,,*45
$GPGSA,A,3,,,,15,17,18,23,,,,,,4.7,4.4,1.5*3F
Die Daten darin bedeuten je nach Satz (GPRMC usw.) immer was anderes.

Mit einem Selektor könnte ich jetzt (in falscher C-Syntax, will grad nicht nachgucken) schreiben:
Code:
char *sel; 
malloc(sel,7);
strncpy(sel,data,6); // z.B. $GPRMC
sel[6]=0;

sel(data); // hier wird die Funktion $GPRMC oder die Funktion $GPGGA usw. 
              // aufgerufen, geht natürlich nicht in C
Und jede Funktion kann genau ihren Satz parsen. Ich brauche keine 20 if-Abfragen schreiben.
Das genau macht der Selektor und ich finde das cool und hilfreich.
 
  • Gefällt mir
Reaktionen: frauenPower
@Gondomir

Danke Dir für Deine Einschätzung.

Hinsichtlich Deines Beispiels: Nichts verstanden. Aber noch nicht einmal ansatzweise.

Liebe Grüße
Karin
 
Ich habe verschiedene Datensätze die entweder mit GPRMC oder GPGGA oder GPGSV usw. (das $ lass ich mal weg) beginnen. Und genau der NSString der eben nur GPRMC oder GPGGA usw. enthält ist der Name der Methode den ich aufrufen will. Die Daten bestimmen durch Ihren Inhalt selbst, wie die Methode heisst, die die Daten verarbeitet.
 
ahhh,
dass hört sich gut an.

Vielleicht kennt jemand ein Beispiel, gerne in einem Buch, mit dem man mal spielen kann?

@Gondomir
Nochmals Danke.

Liebe Grüße
Karin
 
Zurück
Oben Unten