Fehler zu offensichtlich?

  • 1: Ja, Systaxfehler "…" :).
    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.

    So funktionierst bestimmt :):

    Quellcode

    1. - (BOOL)isEqualToPerson:(Person*)other
    2. {
    3. …
    4. if( ![ohter isEqualToPerson:this] ) { return NO; }
    5. …
    6. }
    Inos ist ein Gott aus Gothic, dem Spiel.

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

  • Deine Lösung ist jedenfalls eine Endlosrekursion.

    Neee, es wird ja gerade -isEqualToPerson: implementiert. Da werden halt verschiedene Eigenschaften verglichen, also auch noch andere. Person war auch nur ein Beispiel. Insgesamt steht da meinetwegen

    Quellcode

    1. - (BOOL)isEqualToMyClass:(MyClass*)other {
    2. if( self == other ) return YES;
    4. if( ![self.property1 isEqual:self.property1] ) return NO;
    5. if( ![self.property2 isEqual:self.property2] ) return NO;
    6. if( ![self.property3 isEqual:self.property3] ) return NO;
    8. return YES;
    9. }

    Aber darum geht es nicht. Es geht um jden einzelnen Vergleich, weshalb ich oben nur den einen hinschreib.
    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"?

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Amin Negm-Awad ()

  • Lösung:Die Entitäten sind gleich, wenn alle Eigenschaften gleich sind. Eigenschaften können aber nil sein. Dann besteht Gleichheit der Eigenschaft, wenn beide Entitäten diese Eigenschaft auf nil haben. -isEqual… liefert dann aber NO, weil eine Message to nil bei einem Returntypen BOOL immer NO liefert.
    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:

    Lösung:Die Entitäten sind gleich, wenn alle Eigenschaften gleich sind. Eigenschaften können aber nil sein. Dann besteht Gleichheit der Eigenschaft, wenn beide Entitäten diese Eigenschaft auf nil haben. -isEqual… liefert dann aber NO, weil eine Message to nil bei einem Returntypen BOOL immer NO liefert.

    macmoonshine schrieb:

    Was ist denn, wenn eine Property nil ist?


    problem tritt nur auf wenn beide properties nil sind. er erwartet dann YES, es kommt aber logischerweise NO dabei raus.

  • MCDan schrieb:

    Kann self.name evtl. auch nil sein? Dann liefert [self.name isEqualToPerson:other.name] natürlich NO zurück, egal welchen Wert other.name hat.

    So sollte es funktionieren:

    Quellcode

    1. if (self.name != other.name)
    2. if (![self.name isEqualToString:other.name])
    3. return NO;

    Nö, das funktioniert auch nicht. Besser ist

    Quellcode

    1. if(self.name != nil && ![self.name isEqualToString:other.name])


    Ich würde aber die Methode so schreiben, dass die Vergleiche positiv formuliert sind.
    „Meine Komplikation hatte eine Komplikation.“

  • MCDan schrieb:

    macmoonshine schrieb:

    Was ist denn, wenn eine Property nil ist?

    Wenn das Property von other nil ist, gibt es keine Probleme. Allerdings wird bei isEqualToString: immer NO zurückgegeben wenn das Property von self und other nil ist. Die Methode isEqualToPerson: sollte jedoch kein NO zurück geben, wenn das Property von self und other nil ist.


    es gibt auch keine probleme wenn nur das property von self nil ist denn dann wird ja korrekterweise NO zurückgeleifert.
    problem gibts nur wenn beide nil sind ;)

  • macmoonshine schrieb:

    MCDan schrieb:

    Kann self.name evtl. auch nil sein? Dann liefert [self.name isEqualToPerson:other.name] natürlich NO zurück, egal welchen Wert other.name hat.

    So sollte es funktionieren:

    Quellcode

    1. if (self.name != other.name)
    2. if (![self.name isEqualToString:other.name])
    3. return NO;

    Nö, das funktioniert auch nicht. Besser ist

    Quellcode

    1. if(self.name != nil && ![self.name isEqualToString:other.name])


    Ich würde aber die Methode so schreiben, dass die Vergleiche positiv formuliert sind.


    warum sollte das nicht funktionieren?

    und auch wenn man die vergleiche positiv formuliert hat man das selbe problem plus noch zusätzlich das problem der schlechteren lesbarkeit

  • gritsch schrieb:

    MCDan schrieb:

    macmoonshine schrieb:

    Was ist denn, wenn eine Property nil ist?

    Wenn das Property von other nil ist, gibt es keine Probleme. Allerdings wird bei isEqualToString: immer NO zurückgegeben wenn das Property von self und other nil ist. Die Methode isEqualToPerson: sollte jedoch kein NO zurück geben, wenn das Property von self und other nil ist.


    es gibt auch keine probleme wenn nur das property von self nil ist denn dann wird ja korrekterweise NO zurückgeleifert.
    problem gibts nur wenn beide nil sind ;)

    Stimmt natürlich!

  • Dass hier immer die Diskussion nach der Lösung losgeht.

    a) Richtig, das Problem tritt auf, wenn beide nil sind. Denn nur in diesem Fall gibt es einen False-Negativ. Ist self.prop nil und der andere nicht nil, ist das NO – gleichsam zufällig – richtig. Im umgekehrten Fall wird ein ordentlicher Vergleich durchgeführt (mit nil, was aber isEqual…: vertragen muss).

    b) Positive Vergleiche mache ich nicht, weil ich die schachteln müsste. Dazu ist mein Monitor zu klein.
    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"?

  • "Deine Lösung ist jedenfalls eine Endlosrekursion."
    War auch nur ein Scherz und darum das Smiley

    Das aber auch nicht immer, wenn self.name oder other.name nil ist dann nicht.

    Amin Negm-Awad schrieb:

    Dass hier immer die Diskussion nach der Lösung losgeht.

    a) Richtig, das Problem tritt auf, wenn beide nil sind. Denn nur in diesem Fall gibt es einen False-Negativ. Ist self.prop nil und der andere nicht nil, ist das NO – gleichsam zufällig – richtig. Im umgekehrten Fall wird ein ordentlicher Vergleich durchgeführt (mit nil, was aber isEqual…: vertragen muss).

    b) Positive Vergleiche mache ich nicht, weil ich die schachteln müsste. Dazu ist mein Monitor zu klein.
    "Richtig, das Problem tritt auf, wenn beide nil sind."?
    Eine Nachricht nach nil ist nil.
    Wenn beide Namen nil sind, dann können die Personen nicht identifiziert werden und somit ist false richtig.
    Wie kann man sagen, dass zwei Personen gleich sind, wenn man nicht weiß wer das überhaupt ist?
    Inos ist ein Gott aus Gothic, dem Spiel.

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

  • Inos schrieb:

    Wenn beide Namen nil sind, dann können die Personen nicht identifiziert werden und somit ist false richtig.

    Was soll denn das werden?
    Rennst du mit geschlossenen Augen durch die Welt und lässt dir von jedem den Namen in Blindenschrift präsentieren?

    Mensch kann sehr wohl Personen identifizieren, ohne ihre Namen zu wissen.
    Passiert mir permanent...

    Es lassen sich natürlich permanent irgendwelche konstruierten Beispiele finden, mit dessen Hilfe man seinen Standpunkt zementieren kann.
    Beispiel gefällig? Zwei Personen haben ein miserables Namens- aber ein exzellentes Zahlengedächtnis.

    Sie können sich nicht an ihren Namen erinnern und haben leider keine Dokumente zur einwandfreien Identifizierung dabei. (Strafrechtliche Folgen mal unberücksichtigt gelassen)
    Doch dank ihres genialen Zahlengedächtnisses kennen sie ihre Personalausweisnummer auswendig.
    Kann man diese Personen identifizieren?
    «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

  • "Es lassen sich natürlich permanent irgendwelche konstruierten Beispiele finden, mit dessen Hilfe man seinen Standpunkt zementieren kann."
    Nein!!!, das hatte ich von Anfang an so gedacht.
    Darum hatte ich auch zum Anfang geschrieben, was genau sein Ziel ist!

    Nein, man kann zwei Personen ohne den Namen nicht identifizieren, außer du hast seinen genetischen Fingerabdruck oder vergleichbares.
    "Kann man diese Personen identifizieren?"
    Ja, aber durch diese Nummer gelangt man an weitere Daten wie den Namen.
    Inos ist ein Gott aus Gothic, dem Spiel.

  • Dass der Name ein identifizierende Schlüssel auf die Person ist, ist aber schon deshalb nicht richtig, weil es sich nicht um einen Primärschlüssel handelt. Würden Menschen über ihre Namen identifiziert, dann hätten wir deutlich weniger auf der Welt. Außerdem haben Menschen in ihren ersten Tagen in der Tat keinen Namen.

    Aber wie dem auch sei: Ihc hatte ja scho darauf hingewiesen, dass es sich um ein Beispiel handelt. Da muss man nicht Phantasie über das Wesen des Namens für die Existenz – zumal in einer unbekannten – Software walten lassen.

    Das Ziel ergibt sich überigens 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"?

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Amin Negm-Awad ()

  • "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.
    Hättest du nur den Namen verwendet, dann könne man doch überhaupt nicht sagen, ob das identische Personen sind.
    Inos ist ein Gott aus Gothic, dem Spiel.