Punkt Notation

  • Lucas de Vil schrieb:

    Und du willst hässliche C-Skalare-Angewohnheiten auf hübsche Objective-C-Objekte anwenden.
    Pfuibäh.

    Schönheit liegt im Sinne des Betrachters ;) Für mich ist das Ur-Ansi-C mmer noch stylistisch die schönste Sprache der Welt. Einfach und effektiv ohne großes rumgeschwalle.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

    Pre-Kaffee-Posts sind mit Vorsicht zu geniessen :)

  • Thallius schrieb:

    Lucas de Vil schrieb:

    Und du willst hässliche C-Skalare-Angewohnheiten auf hübsche Objective-C-Objekte anwenden.
    Pfuibäh.

    Schönheit liegt im Sinne des Betrachters ;) Für mich ist das Ur-Ansi-C mmer noch stylistisch die schönste Sprache der Welt. Einfach und effektiv ohne großes rumgeschwalle.

    Für C bin ich da 100% einverstanden. Und für eine Objekterweiterung ist es eben Obj-C 1.0. Die Regeln haben mal auf eine Seite gepaßt.
    Alles andere (C99, gcc, Obj-C++, Obj-C 2.0) sind überwiegend nur scheinbare Verbesserungen, wobei es natürlich für jedes Detail eine Begründung gibt. Aber die geht i.d.R. nicht mehr vom ursprünglichen Designprinzip aus, sondern von tagesaktuellen scheinbaren Schwachpunkten.

  • Lucas de Vil schrieb:

    Wenn eine Instanzvariable entfallen kann, weshalb will ich dann weiterhin intern auf ihren Setter zugreifen müssen?
    Sie kann ja nur deshalb entfallen, weil sie unnötig geworden ist. Im Sinne der Lesbarkeit gehören dann sämtliche verwirrenden Altlasten ebenfalls entfernt.
    Da liegt doch ein Fehler in der Planung. :P

    Ich sehe das anders! Eine Instanzvariable ist meist nur eine Art der Datenhaltung. Wenn die Datenhaltung in einer Klasse modifiziert wird, weil (beispielsweise) ein Wert nicht mehr gespeichert, sondern bei Bedarf generiert/errechnet wird, so bedeutet das nicht automatisch, dass diese Daten nie wieder benötigt werden. Wird immer nur per Getter darauf zugegriffen, so kann ich auch viel leichter beispielsweise auf "lazy loading" umstellen – indem nur der Getter angepasst wird und nicht sämtliche Aufrufe!

    McPringle
    Flattr this

  • McPringle schrieb:

    Lucas de Vil schrieb:

    Wenn eine Instanzvariable entfallen kann, weshalb will ich dann weiterhin intern auf ihren Setter zugreifen müssen?
    Sie kann ja nur deshalb entfallen, weil sie unnötig geworden ist. Im Sinne der Lesbarkeit gehören dann sämtliche verwirrenden Altlasten ebenfalls entfernt.
    Da liegt doch ein Fehler in der Planung. :P

    Ich sehe das anders! Eine Instanzvariable ist meist nur eine Art der Datenhaltung. Wenn die Datenhaltung in einer Klasse modifiziert wird, weil (beispielsweise) ein Wert nicht mehr gespeichert, sondern bei Bedarf generiert/errechnet wird, so bedeutet das nicht automatisch, dass diese Daten nie wieder benötigt werden. Wird immer nur per Getter darauf zugegriffen, so kann ich auch viel leichter beispielsweise auf "lazy loading" umstellen – indem nur der Getter angepasst wird und nicht sämtliche Aufrufe!

    Soweit richtig. Aber.
    Nachdem du die Instanzvariable entfernt hast, kannst du nicht mehr auf ihren Getter zugreifen.
    Du greifst auf eine Methode zu, die genauso heißt wie der Getter der Instanzvariablen zuvor hieß.

    Wenn du jetzt auch noch aus Zeitersparnisgründen den @property und @synthesize Krams nicht rauswirfst, hast du nach wie vor eine Instanzvariable und nutzt sie schlicht nicht -> Fehler in der Planung, unsauberer Code.

    Nachdem du $irgendwas an der Datenhaltung deines Objekts geschraubt hast, dann musst du $überall verifizieren, dass das sinnvoll war und fehlerfrei geklappt hat.
    Du verlässt dich darauf, dass die Methode schon irgend etwas Brauchbares liefert. Ich gehe jeden einzelnen Aufruf der Instanzvariablen durch und prüfe, ob ich ihre Werte hier überhaupt noch brauche. Falls dem so ist, ändere ich den Aufruf auf die Methode; falls nicht, wird das gesamte Codefragment angepasst.


    Weiteres Contradingens:
    Ich nutze gern und viel veränderliche Container.
    Die Getter liefern immer immutable Objekte (meist Kopien) zurück, der Setter erstellt aus dem übergebenen immutablen Objekt eine veränderliche Kopie.
    Nach außen hin ist das ja auch sinnvoll.

    Ich kann mir jetzt also entweder je einen neuen Setter und Getter für das mutable Objekt bauen - oder direkt auf das mutable Objekt zugreifen.
    (Natürlich immer vor dem Hintergrund, dass ich in meiner eigenen Klasse bin.)

    KVO war da das passendste Schlagwort, doch auch das benötigt bei veränderlichen Objekten weitere Anpassungen.
    Zumal mir schleierhaft ist aus welchem Grund mein Objekt seine eigenen Properties observieren möchte. Andererseits komme ich ja vielleicht noch einmal in die Situation, in der das notwendig ist. :)
    «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 kann ja auch sein, dass jemand anderes deine properties observieren möchte. Veränderungen direkt an den instanzvariablen triggern dann keine KVO-Notifications (wenn man diese nicht selbst in der Implementation mit -willChangeValueForKey und -didChangeValueForKey auslöst, aber da ist viel einfacher gleich direkt die accessoren zu benutzen). Das führt dann zu schwer zu debuggenden Verhalten. Die Vorteile der Kapselung liegen auf der Hand und wurden hier ja schon genannt.

  • Lucas de Vil schrieb:

    McPringle schrieb:

    Zum Thema "Getter für eigene Instanzvariablen nutzen": Wenn in einer Klasse auch für den Zugriff auf Instanzvariablen Getter benutzt werden, hat das den unschlagbaren Vorteil, dass die Instanzvariable im Zuge der Evolution der Klasse jederzeit entfallen kann, sofern der Getter noch das erwartete liefert – ohne Modifikationen ausserhalb des Getters! Würde direkt auf die Instanzvariable zugegriffen werden, müsste in diesem Fall jeder einzelne Aufruf angepasst werden: Mühselig!

    McPringle

    Wenn eine Instanzvariable entfallen kann, weshalb will ich dann weiterhin intern auf ihren Setter zugreifen müssen?
    Sie kann ja nur deshalb entfallen, weil sie unnötig geworden ist. Im Sinne der Lesbarkeit gehören dann sämtliche verwirrenden Altlasten ebenfalls entfernt.
    Da liegt doch ein Fehler in der Planung. :P
    […]

    Setter? Computed-Propertys …
    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:

    Computed-Propertys …

    sind meines Wissens Methoden, keine Getter.
    (immer vor dem Hintergrund: Getter sind spezielle Methoden, die eine Instanzvariable zurückgeben. Eine Methode, die Computed-Properties zurückgibt, kann also kein Getter sein. :P)

    Markus Müller schrieb:

    Es kann ja auch sein, dass jemand anderes deine properties observieren möchte. Veränderungen direkt an den instanzvariablen triggern dann keine KVO-Notifications (wenn man diese nicht selbst in der Implementation mit -willChangeValueForKey und -didChangeValueForKey auslöst, aber da ist viel einfacher gleich direkt die accessoren zu benutzen). Das führt dann zu schwer zu debuggenden Verhalten.

    Richtig. Ich rede dennoch weiterhin davon, die Getter in der eigenen Klasse wegzulassen. (Tippfehler meinerseits in Beitrag #36)
    Getter verändern meines Wissens in keinem Fall die Property. Wenn ich Properties direkt ändere, dann auch in self via Setter.
    Doch auch hier: nutze ich meinen Getter, um ein mutables Objekt zu kommen und ändere es dann direkt, triggert keine KVO-Notification - ich müsste das veränderte Array erst setzen.

    Sicherlich ist für so etwas [self extendArrayWithObject:object] sinnvoller, da man dann in der jeweiligen Methode die KVO-Notifications händisch feuern kann.
    Aber zum Thema 'Besseres KVC' hat Amin in seinen Tutorials ja schon reichlich getippt.
    «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

  • Lucas de Vil schrieb:

    Amin Negm-Awad schrieb:

    Computed-Propertys …

    sind meines Wissens Methoden, keine Getter.
    (immer vor dem Hintergrund: Getter sind spezielle Methoden, die eine Instanzvariable zurückgeben. Eine Methode, die Computed-Properties zurückgibt, kann also kein Getter sein. :P)
    […]

    Dann ist dein Wissen falsch.
    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"?