Wieder: setKeys:triggerChangeNotificationsForDependentKey:

  • Wieder: setKeys:triggerChangeNotificationsForDependentKey:

    Hallo,
    jede Klasse kann ja ihre eigenen "dependent" keys setzen - Stichwort:

    Quellcode

    1. + (void)setKeys:(NSArray *)keys triggerChangeNotificationsForDependentKey:(NSString *)dependentKey


    Habe ich es richtig erfasst, dass in dem keys Array nur keys und keine keyPaths stehen dürfen? Der dependentKey darf allerdings ein keyPath sein. Jedenfalls haben dies meine Tests ergeben. Nun frage ich mich, wieso dem so ist.
    Die Objective-Cloud ist fertig wenn sie fertig ist. Beta heißt Beta.

    Objective-C und Cocoa Band 2: Fortgeschrittene
    Cocoa/Objective-C Seminare von [co coa:ding].

  • RE: Wieder: setKeys:triggerChangeNotificationsForDependentKey:

    Ja, hast du.
    Wieso versuche ich dir zu erklären wenn die Wirkung des Alkohols nachlässt. ;)
    «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

  • RE: Wieder: setKeys:triggerChangeNotificationsForDependentKey:

    Wenn du einen Key-Path zulassen würdest, dann würdest du das Triggern eines anderen Objektes erlauben, denn ab dem zweiten Element eines Pfades wird dieser nicht mehr auf self, sondern auf den Rückgabewert des vorangegangenen Pfades angewendet.

    Dies ist etwas schräg, müsste ständig nachgehalten werden und dürfte einige Probleme in der Implementierung bereiten.
    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"?