-init Methode überschrieben: Welchen Sinn hat das, in diesem Fall?

  • Amin Negm-Awad schrieb:

    Ich bin Fachmann
    Das denke ich mir und habe ich auch nie angezweifelt. :)

    Amin Negm-Awad schrieb:

    Es kommt nicht darauf an, was ich weiß. Es kommt auch nicht darauf an, was ein Entwickler bei Apple weiß. Es kommt darauf an, was dokumentiert ist. Und das ist ganz einfach: Du musst in -init… den Designated-Initializer der Superklasse aufrufen.
    Das ich mit self = [super init]; den Designated-Initalizer der Superklasse aufrufen muss, war ja nicht mein Problem. Ich wollte wissen, warum ich in der if-Verzweigung den Variablen einen leeren String ([NSString string]) zuweisen muss ...

    ... weil es manchmal vorkommen kann, dass ein Objekt ein nil nicht akzeptiert und z.B. einen String verlangt.

  • TheFuriousLion schrieb:

    Amin Negm-Awad schrieb:

    Ich bin Fachmann
    Das denke ich mir und habe ich auch nie angezweifelt. :)

    Amin Negm-Awad schrieb:

    Es kommt nicht darauf an, was ich weiß. Es kommt auch nicht darauf an, was ein Entwickler bei Apple weiß. Es kommt darauf an, was dokumentiert ist. Und das ist ganz einfach: Du musst in -init… den Designated-Initializer der Superklasse aufrufen.
    Das ich mit self = [super init]; den Designated-Initalizer der Superklasse aufrufen muss, war ja nicht mein Problem. Ich wollte wissen, warum ich in der if-Verzweigung den Variablen einen leeren String ([NSString string]) zuweisen muss ...

    ... weil es manchmal vorkommen kann, dass ein Objekt ein nil nicht akzeptiert und z.B. einen String verlangt.

    Konnte ich dem hier echt nicht entnehmen:
    "die Variable(?) self steht für die Basisklasse, also für das Objekt, was diese Methode aufgerufen hat, was in diesem Fall die Klasse "Person" ist. Und mit der Nachricht [super init] wird die init Methode der Superklasse - in diesem Fall NSObject - ausgeführt und der Rückgabewert der Variable self übergeben und dann wird mit einer if-Verzweigung überprüft, ob self nicht null ist (self != nil).

    Aber was hat das für einen Sinn? Die Ausgabe am Log funktioniert auch, wenn ich die - init Methode der Superklasse nicht überschriebe. Ich erkenne den Mehrwert nicht ..."

    Aber zum Thema:

    Quellcode

    1. person = …;
    2. NSMutableString *longerName = [person.lastname mutableCopy];
    3. [longerName append:@"-Awad"];

    macht was, wenn lastname nil ist?

    Und was macht es, wenn lastname @"" ist?

    Was du da erwartest bzw. anbietest, ist letztlich eine Frage, was du für deine Klasse festlegst.

    Aber bitte bedenken: NULL is not zero! Oder hier angepasst: nil is not @""
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Es macht etwas aus. Und das solltest du auch verstanden haben.

    nil bedeutet: Nichts gespeichert.
    @"" bedeutet: 0-String (leerer String) gespeichert.

    Ein leerer String ist etwas komplett anderes als kein String.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    Es macht etwas aus. Und das solltest du auch verstanden haben.

    nil bedeutet: Nichts gespeichert.
    @"" bedeutet: 0-String (leerer String) gespeichert.

    Ein leerer String ist etwas komplett anderes als kein String.
    Tut mir leid, ich hab es nicht verstanden. Was macht es, ob es ein leerer String ist, oder eben nil. Es funktioniert beides, auch wenn es nil ist.

    Bitte versuch es nochmals es mir zu erklären. :)
    Die Leitung auf der ich gerade stehe, dürfte eine sehr große sein. ^^

  • TheFuriousLion schrieb:

    Was macht es, ob es ein leerer String ist, oder eben nil. Es funktioniert beides, auch wenn es nil ist.

    Praxistest.

    C-Quellcode

    1. NSMutableArray * testArray = [NSMutableArray arrayWithCapacity:1];
    2. [testArray addObject:@"Ein String"];
    3. testArray = nil;
    4. [testArray addObject:@"Ein anderer String"];
    «Applejack» "Don't you use your fancy mathematics to muddle the issue!"

    Iä-86! Iä-64! Awavauatsh fthagn!

    kmr schrieb:

    Ach, Du bist auch so ein leichtgläubiger Zeitgenosse, der alles glaubt, was irgendwelche Typen vor sich hin brabbeln. :-P

  • Ich habe dir oben Beispiellose angegeben, bei dem der Unterschied eine Rolle spielt. Führe ihn einmal mit nil und einmal mit @"" aus. Geht auch noch einfacher:

    NSString *lastname = nil;
    NSMutableString *longerName = [lastname mutableCopy];
    [longerName append:@"-Awad"];

    NSString *lastname = @"";
    NSMutableString *longerName = [lastname mutableCopy];
    [longerName append:@"-Awad"];

    Beide Male loggen und wundern.

    +++

    Erläuterung:
    nil ist kein String. An keinen String kann man nichts anhängen.
    @"" ist ein leerer String. An einen leeren String kann man etwas anhängen.
    Es hat noch nie etwas gefunzt. To tear down the Wall would be a Werror!
    25.06.2016: [Swift] gehört zu meinen *Favorite Tags* auf SO. In welcher Bedeutung von "favorite"?

  • Amin Negm-Awad schrieb:

    NSString *lastname = nil;
    NSMutableString *longerName = [lastname mutableCopy];
    [longerName append:@"-Awad"];

    NSString *lastname = @"";
    NSMutableString *longerName = [lastname mutableCopy];
    [longerName append:@"-Awad"];
    Funktioniert beides nicht bei mir. Xcode kennt hier nur die Methoden appendFormat und appendString.

    Amin Negm-Awad schrieb:

    Erläuterung:
    nil ist kein String. An keinen String kann man nichts anhängen.
    @"" ist ein leerer String. An einen leeren String kann man etwas anhängen.
    Jetzt dürfte ich es wieder verstanden haben. :)

    Aber ist das nicht ungefähr das, was ich gesagt habe?
    »... weil es manchmal vorkommen kann, dass ein Objekt ein nil nicht akzeptiert und z.B. einen String verlangt.«