Fehler zu offensichtlich?

  • Amin Negm-Awad schrieb:

    b) Positive Vergleiche mache ich nicht, weil ich die schachteln müsste. Dazu ist mein Monitor zu klein.

    Du kannst die Bedingung den Vergleich aber in einer Bedingung ausdrücken:

    Quellcode

    1. return (self.name == other.name || [self.name isEqualToString:other.name]) && ...;
    Das ist natürlich Geschmackssache. Ich finde aber negative Vergleiche meist schwerer zu verstehen.
    „Meine Komplikation hatte eine Komplikation.“

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von macmoonshine ()

  • Inos schrieb:

    "2: Eine Person kann nicht nur anhand eines Namens unterschieden werden.

    Man weiss nicht was vor und nach den "..." steht, oder was genau dein Ziel ist."
    Ist alles von mir, und wurde zuerst gepostet.

    Du weißt auch nicht, ob welchen Zeichensatz ich im Editor verwende. Ist ebenso irrelevant. Das Ziel ergibt sich aus dem Methodennamen.
    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"?

  • macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    b) Positive Vergleiche mache ich nicht, weil ich die schachteln müsste. Dazu ist mein Monitor zu klein.

    Du kannst die Bedingung aber in einer Bedingung ausdrücken:

    Quellcode

    1. return (self.name == other.name || [self.name isEqualToString:other.name]) && ...;
    Das ist natürlich Geschmackssache. Ich finde aber negative Vergleiche meist schwerer zu verstehen.

    Schreib das mal für drei Propertys hin. Ich nehme an, du hast keine Lust dazu. ;)
    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:

    Schreib das mal für drei Propertys hin. Ich nehme an, du hast keine Lust dazu. ;)

    Quellcode

    1. return (self.name == other.name ||[self.name isEqualToString:other.name) &&
    2. (self.dayOfBirth == other.dayOfBirth || [self.dayOfBirth isEqualToString:other.dayOfBirth) &&
    3. (self.salutation == other.salutation || [self.salutation isEqualToString:other.salutation) &&
    4. (self.street == other.street || [self.street isEqualToString:other.street) &&
    5. (self.city == other.city || [self.city isEqualToString:other.city);

    Geht sogar mit fünf ;)
    „Meine Komplikation hatte eine Komplikation.“

  • McPringle schrieb:

    Hoi!

    macmoonshine schrieb:

    Geht sogar mit fünf
    Sieht aber unübersichtlich aus. Code, bei dem nicht auf den ersten Blick ersichtlich ist, was er macht, fällt bei mir durch… :P

    Gibt einen Wahrheitswert zurück. Sieht man doch auf den ersten Blick. ;)
    Man sieht auch auf den ersten Blick, dass der Code fehlerhaft ist, da die Stringvergleiche keine schließende eckige Klammer haben. ^^
    «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

  • McPringle schrieb:

    Sieht aber unübersichtlich aus. Code, bei dem nicht auf den ersten Blick ersichtlich ist, was er macht, fällt bei mir durch…

    Wenn Du Dir die Bedingung ansiehst, wirst Du eine Struktur erkennen. Sind viele If-Abfragen hintereinander übersichtlicher?

    Lucas de Vil schrieb:

    Man sieht auch auf den ersten Blick, dass der Code fehlerhaft ist, da die Stringvergleiche keine schließende eckige Klammer haben.

    Ich wusste es. Ich muss noch dringend an meinem eingebauten Objective-C-Parser basteln. ;)
    „Meine Komplikation hatte eine Komplikation.“

  • McPringle schrieb:

    Je nach dem. Ich bin ein Verfechter des "return early" Prinzips und mag keine extrem (mehr als drei) zusammen gefasste Bedingungen.
    Kann eine Methode noch früher zurückkehren, als in der ersten Anweisung? ;)

    McPringle schrieb:

    Damit würde es für mich übersichtlicher sein.

    Wie beschreibst Du die Aufgabe der Methode umgangssprachlich?
    „Meine Komplikation hatte eine Komplikation.“

  • Für Modell-Objekte reicht doch meistens die isEqual-Implementierung von NSObject aus, die einfach nur die Zeiger vergleicht. Wieso sollte man ein und die selbe Person durch zwei verschiedene Objekte (an zwei verschiedenen Adressen) repräsentieren wollen? Und in anderen Fällen kann es ja vorkommen, das sich zwei Objekte in allen Eigenschaften identisch sind, aber trotzdem unterschiedlich sind.

  • dergraf schrieb:

    Wieso sollte man ein und die selbe Person durch zwei verschiedene Objekte (an zwei verschiedenen Adressen) repräsentieren wollen?

    Habe ich mich auch schon gefragt und ich denke der Nutzen einer solchen Methode ist wahrscheinlich eher bescheiden. Hängt vielleicht auch ein bisschen vom Anwendungsfall ab. Könnte der in diesem Fall edukativ sein?
    „Meine Komplikation hatte eine Komplikation.“

  • In dem Fall, wären für mich beide Objekte gleich, wenn die Personen identische Daten haben. Der Zeiger wäre für mich unerheblich. Aber wie schon gesagt, ist abhängig vom Anwendungsfall.

  • Nein, es reicht nicht aus.

    Zwei Strings sind ganz gewiss nicht nur gleich, wenn sie denselben Zeiger haben. (Oder ist das keine Modelklasse?) Aber es gibt auch andere Fälle, bei mir etwa Twintoning einer Join-Point-Klasse, die ganz gewiss das Model bildet.

    Collections prüfen die Gleichheit aus diesem Grunde auch mit -isEqual. (Übrigens laut Doku nur dann richtig, wenn sich in der Colection isEqual nicht ändert, womit man eigentlich gar keine veränderlichen Instanzen in Collections schmeißen darf. Tatsächlich kommt es aber wohl nur auf -hash an.)

    Identität und Gleichheit sind einfach zwei völlig verschiedene paar Schuhe.
    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"?

  • wolf_10de schrieb:

    In dem Fall, wären für mich beide Objekte gleich, wenn die Personen identische Daten haben. Der Zeiger wäre für mich unerheblich. Aber wie schon gesagt, ist abhängig vom Anwendungsfall.

    Nö, die siehst das schon richtig. Gleichheit liegt dann vor, wenn zwei Instanzen denselben Inhalt haben. Identität liegt vor, wenn sie denselben Zeiger haben.

    Vom Anwendungsfall hängt ab, ob man Gleichheit oder Identität benötigt, jedoch nicht, ob Gleichheit dasselbe (dasgleiche?) wie Identität ist. (Bei Twintones sollte allerdings die korrekte Implementierung dazu führen, dass es keinen Unterschied gibt.)
    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"?

  • macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Schreib das mal für drei Propertys hin. Ich nehme an, du hast keine Lust dazu. ;)

    Quellcode

    1. return (self.name == other.name ||[self.name isEqualToString:other.name) &&
    2. (self.dayOfBirth == other.dayOfBirth || [self.dayOfBirth isEqualToString:other.dayOfBirth) &&
    3. (self.salutation == other.salutation || [self.salutation isEqualToString:other.salutation) &&
    4. (self.street == other.street || [self.street isEqualToString:other.street) ||
    5. (self.city == other.city || [self.city isEqualToString:other.city);

    Geht sogar mit fünf ;)

    Schöne Laubsägearbeit. *g*

    Ich rate mal, dass wenn in der 4. Zeile statt && ein || stünde, das niemand sehen würde.
    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:

    Gleichheit liegt dann vor, wenn zwei Instanzen denselben Inhalt haben.

    Was der Inhalt für den Vergleich ist, ist aber der Knackpunkt: Der retainCount gehört sicherlich nicht dazu. Angenommen Deine Person hat ein Attribut lastUpdateTime. Wenn zwei Personen sich nur in diesem Attribut unterscheiden, sind sie dann verschieden oder trotzdem gleich? Häufig wird bei Entitäten mit Schlüssel die Gleichheit nur über den Schlüssel definiert. Also zwei Objekte sind gleich, genau dann wenn die Werte ihres Schlüssels gleich sind.
    „Meine Komplikation hatte eine Komplikation.“

  • macmoonshine schrieb:

    Amin Negm-Awad schrieb:

    Schöne Laubsägearbeit. *g*
    Ey, hab' ich Dekupiersäge ;)

    Amin Negm-Awad schrieb:

    Ich rate mal, dass wenn in der 4. Zeile statt && ein || stünde, das niemand sehen würde.

    Stell' Dir mal vor, Du vergisst ein Ausrufezeichen und keiner geht hin ;)

    Das ändert sich ja nicht. Aber in der Tat erwiusche ich mich genau aus diesem Grund häufig beim Tippen von != nil und == NO. (Was auch ansonsten richtig ist.)
    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"?

  • zerm schrieb:

    Amin Negm-Awad schrieb:

    Das ändert sich ja nicht. Aber in der Tat erwiusche ich mich genau aus diesem Grund häufig beim Tippen von != nil und == NO. (Was auch ansonsten richtig ist.)

    Wenn schon, dann bitte "NO==", damit es gar nicht passieren kann, dass man versehentlich etwas zuweist anstelle zu vergleichen ;)

    … und dann falle ich bei "boolVar ==" gleich wieder herein? Wer hat sich bloß diesen Trick ausgedacht, der nur manchmal funktioniert?

    Natürlich kompiliere ich mit -Wall und der gcc teilt mir so etwas mit … ;)
    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"?