performSelector mit mehreren Argumenten

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • performSelector mit mehreren Argumenten

    Hallo Zusammen,

    ich bin neulich darüber gestolpert, dass ich bei einem performSelector: call mehrere Argumente übergeben wollte. Ich war etwas perplex, dass ich das vorher anscheinend nie brauchte. Darüber gestolpert bin ich als ich eine Funktionsaufruf in eine Sequenz aus SKActions einbinden wollte. Natürlich kann man das mit ^blocks umgehen, aber dennoch interessiert mich nun: wie geht sowas?

    Quellcode

    1. SKAction *callFight = [SKAction performSelector:@selector(handleFightWithDefender:andAttacker:) onTarget:self];
    3. - (void)handleFightWithDefender:(GameToken*)defenderToken andAttacker:(GameToken*)attackerToken
    4. {
    5. // awesome stuff
    6. }


    Schönen Gruß und Danke.

  • Ja, aber mit einem Dictionary machst Du Dir die schöne selbsterklärende Methoden-Signatur zunichte. Auch nicht schön, und vor allem geht das nicht, wenn Du die Methoden-Signatur nicht ändern kannst. Mit NSInvocation geht's mit ein wenig mehr Aufwand, allerdings muss man sich da bei ARC die Speicherverwaltung genauer ansehen.

    ciao

    gandhi

  • Danke an Alle für die Antworten. Ich habe mich noch mal dem Thema gewidmet und viele neue Fragen bekommen.

    Was ist der Unterschied zwischen

    Quellcode

    1. [self performSelector:@selector(test:) withObject:headerLabel1];

    und

    Quellcode

    1. [self test:headerLabel1];

    ?

    Des Weiteren bin ich irritiert, dass es da offensichtlich keinen einfachen Weg zu geben scheint. Es geht aus meiner ursprünglichen Frage nicht ganz hervor - ich wollte den Methodenaufruf in einer SKAction sequence einbetten. Wenn ich die Antworten hier richtig verstehen, geht das mit keine der vorgeschlagenen Lösungen. Gibt es vielleicht an jedem Objekt einen kleinen Speicherort an dem man ein Dictionary übergeben kann? Dann könnte ich darin meine Objekte ablegen dem sender anheften und eine Mediationsmethode zwischenschalten.

    Oder wie gesagt mit ^blocks arbeiten. So was wie

    Quellcode

    1. SKAction *run = [SKAction runBlock:^(void){
    2. [self handleFightWithDefender:defenderToken andAttacker:attackerToken];
    3. }]


    Aber so richtig schön ist das alles nicht.

  • macmoonshine schrieb:

    Der Unterschied zwischen beiden Varianten: In der ersten Variante kannst Du für den Selektor eine Variable verwenden:

    Quellcode

    1. ​SEL theSelector = ...; // Magic code
    3. [self performSelector:theSelector withObject:headerLabel1];


    ioscampus schrieb:

    Aber so richtig schön ist das alles nicht.

    Was ist an Blocks nicht schön?


    Blöcke sind praktisch aber schön sind sie beim besten Willen nicht. Weder in Syntax noch in Lesbarkeit.

    Gruss

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

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

  • Thallius schrieb:

    Blöcke sind praktisch aber schön sind sie beim besten Willen nicht. Weder in Syntax noch in Lesbarkeit.

    Das kann ich nicht nachvollziehen. Die Block-Syntax ist auf den ersten Blick zwar etwas gewöhnungsbedürftig, aber auf den zweiten ziemlich konsistent zu C (und sie sind halt eine Erweiterung von C, nicht von Obj-C). Über Lesbarkeit kann man streiten, aber erstens glaube ich, dass Lesbarkeit primär eine Sache des Programmierers und nicht der Sprache ist (wenn man will kann man sogar lesbaren Perl-Code schreiben) und zweitens ist es nicht weniger schlimm, eine halbwegs komplizierte NSInvocation lesbar zusammenzustückeln, geschweige denn, das anschließend zu lesen - da ist ein Block das kleinere Übel.

    performSelectorWithSonstwas: und NSInvocation sind vielleicht noch nicht tot, aber sie riechen mittlerweile schon ziemlich muffig. Sie kommen aus einer Ära vor Blöcken, nach meinem Geschmack haben sie im Wesentlichen ausgedient.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:


    performSelectorWithSonstwas: und NSInvocation sind vielleicht noch nicht tot, aber sie riechen mittlerweile schon ziemlich muffig. Sie kommen aus einer Ära vor Blöcken, nach meinem Geschmack haben sie im Wesentlichen ausgedient.


    Seh' ich auch so. Was mir auch an Blöcken gefällt, ist die Tatsache, dass ich oft logisch zusammenhängen Code auf einen Blick erfassen kann. Man schaue sich z.B. mal die NSArray-Methode "sortedArrayUsingSelector:" an. Will man verstehen, wie sortiert wird, muss man sich im Code nochmal die entsprechende Methode raussuchen. Bei "sortedArrayUsingComparator" kommt gleich danach der Block und ich sehe auf einen Blick was passiert.

    schönen Gruß

    gandhi

  • gandhi schrieb:

    mattik schrieb:


    performSelectorWithSonstwas: und NSInvocation sind vielleicht noch nicht tot, aber sie riechen mittlerweile schon ziemlich muffig. Sie kommen aus einer Ära vor Blöcken, nach meinem Geschmack haben sie im Wesentlichen ausgedient.


    Seh' ich auch so. Was mir auch an Blöcken gefällt, ist die Tatsache, dass ich oft logisch zusammenhängen Code auf einen Blick erfassen kann. Man schaue sich z.B. mal die NSArray-Methode "sortedArrayUsingSelector:" an. Will man verstehen, wie sortiert wird, muss man sich im Code nochmal die entsprechende Methode raussuchen. Bei "sortedArrayUsingComparator" kommt gleich danach der Block und ich sehe auf einen Blick was passiert.

    schönen Gruß

    gandhi


    mit ersterem kann ich ein array von strings aber an X stellen im code numerisch sortieren lassen wenn ich eine entsprechende methode einmal in einer NSString-Kategorie implementiert habe. mit blocks müsste ich die jedesmal aufs neue reintippen (in dem fall keine alllzugroße arbeit aber es gibt auch komplexere fälle)

  • gritsch schrieb:

    oder schreibt ihr alle nur neue programme?

    Hast du noch Sachen, die vor 10.6 laufen müssen? Nein, die habe ich rausgeschmissen. Support für 10.6 und 10.7 fliegt bei der nächsten Gelegenheit auch raus, macht einfach keinen Spaß mehr.

    Der Code ist teilweise natürlich älter. Da sind auch NSInvocations und allerhand anderer Schätze drin. Die bleiben da so lange, bis ich aus irgend welchen Gründen wieder an den Code muss, dann werden sie meistens großräumig per Refactoring rausgeschmissen. Das ist die einzige Chance, den Code ordentlich zu erhalten. Glücklicherweise kann ich das bei den meisten Projekten tun, ohne das ewig gegenüber irgendwelchen Leuten argumentieren zu müssen.
    Multigrad - 360°-Produktfotografie für den Mac

  • mattik schrieb:

    gritsch schrieb:

    oder schreibt ihr alle nur neue programme?

    Hast du noch Sachen, die vor 10.6 laufen müssen? Nein, die habe ich rausgeschmissen. Support für 10.6 und 10.7 fliegt bei der nächsten Gelegenheit auch raus, macht einfach keinen Spaß mehr.

    Der Code ist teilweise natürlich älter. Da sind auch NSInvocations und allerhand anderer Schätze drin. Die bleiben da so lange, bis ich aus irgend welchen Gründen wieder an den Code muss, dann werden sie meistens großräumig per Refactoring rausgeschmissen. Das ist die einzige Chance, den Code ordentlich zu erhalten. Glücklicherweise kann ich das bei den meisten Projekten tun, ohne das ewig gegenüber irgendwelchen Leuten argumentieren zu müssen.


    sehe ich doch genauso - nur stelle ich nicht alles um nur weil es ein neues feature gibt. wenn es keinen vorteil ergibt bleibe ich eben bei dem alten. never change a running system ;)

  • Thallius schrieb:

    macmoonshine schrieb:



    ioscampus schrieb:

    Aber so richtig schön ist das alles nicht.

    Was ist an Blocks nicht schön?


    Blöcke sind praktisch aber schön sind sie beim besten Willen nicht. Weder in Syntax noch in Lesbarkeit.

    Gruss

    Claus


    Mir geht es so wie Thallius. Es fühlt sich aufgebläht an 3 Zeilen Code zu nutzen, wenn es eigentlich eine sein könnte, würde es nur die passende Methode geben (egal ob jetzt SKAction, NSTimer oder oder). Es fühlt sich wie ein Workaround an.

    Naja, ich habe jetzt gelernt, dass es anscheinend ein vollkommen akzeptierter Weg ist. Dann fühle ich mich in Zukunft bestimmt besser das auch so zu nutzen.