Namenskonvention s. Praefix

  • Namenskonvention s. Praefix

    Hi,

    einerseits sollen ja Methoden die etwas allozieren (und nicht [auto]releasen) mit new oder alloc beginnen.

    Anderseits macht es Sinn dass Delegate-Methoden mit einem quasi-Praefix anfangen, damit man es besser zuordnen kann und auch Namenskonflikte zwischen Delegates vermieden werden.

    Wie loest Ihr diesen Widerspruch? ;)

    Ekki

  • Die Namenskonvention mit new, alloc oder copy gilt nur für Methoden, bei denen der Aufrufer die Eigentümerschaft erhält. Wenn Deine Delegates irgendwelche Objekte erzeugen, dann können Sie die Objekte einfach auf den Autoreleasepool legen.

    Übrigens ist der erste Namensbestandteil von Delegatemethoden in der Regel der Klassenname der delegierenden Klasse ohne das Frameworkprefix (wie z. B. application:didFinishLaunchingWithOptions:).
    „Meine Komplikation hatte eine Komplikation.“

  • ja schon klar, aber nur wegen einer Namenspolicy das Objekt autoreleasen?!

    genau das ist ja der Wid.spruch: was, wenn application eine solche Methode hat (warum auch immer)... applicationAlloc vs. allocApplication... habe ein konkretes Szenario wo Autorelease nicht passt...

    ja, okay, ich gebe zu, es gibt andere Probleme auf der Welt... ;)

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von CI-CUBE ()

  • CI-CUBE schrieb:

    genau das ist ja der Wid.spruch: was, wenn application eine solche Methode hat (warum auch immer)... applicationAlloc vs. allocApplication... habe ein konkretes Szenario wo Autorelease nicht passt...

    alloc würde ich sowieso nur für Methoden verwenden, die Speicher reservieren ohne ihn zu initialisieren. Neben dem Unterschied bei der Speicherverwaltung, haben ja die Namensbestandteile alloc (Speicher reservieren), new (neues, initialisiertes Objekt anlegen), copy (neues Objekt als Kopie eines bestehenden anlegen) und mutableCopy (neue veränderliche Kopie eines Objekts anlgen) auch noch eine feste Bedeutung.
    „Meine Komplikation hatte eine Komplikation.“

  • also in der Delegate-Methode auto-releasen, dann im aufrufenden, spez. Kontext retainen, spaeter dann im existierenden Code das release... wuerde gehen, da das Objekt ja retourniert wird und somit das autorelease nicht vor dem retain aufgerufen werden wuerde...

    ja, wuerde wohl gehen... aber eigentlich war meine Frage doch eine ganz andere! Aber okay, habe verstanden. Der Widerspruch existiert (es ist ja schliesslich nicht verboten, dass eine Delegate-Methode ein Objekt mit Retain = 1 zurueckliefert), also hat man 2 Moeglichkeiten:

    (1) man verletzt die Namenspolicy (also applicationNew oder newApplication - habe mich fuer ersteres entschieden) oder
    (2) man macht generell keine Delegate-Signaturen die konsequenterweise mit new/alloc beginnen sollten

    Hammer's? ;)

  • CI-CUBE schrieb:

    Der Widerspruch existiert (es ist ja schliesslich nicht verboten, dass eine Delegate-Methode ein Objekt mit Retain = 1 zurueckliefert), also hat man 2 Moeglichkeiten:

    Es ist kein Widerspruch. Das wäre es nur, wenn dazu eine Notwendigkeit bestünde. Die besteht aber nicht. Wenn Du die Namensregel verletzt, kommt übrigens der Analyzer und meines Wissens auch Leaks durcheinander.

    CI-CUBE schrieb:

    (2) man macht generell keine Delegate-Signaturen die konsequenterweise mit new/alloc beginnen sollten

    Mit alloc schon mal gar nicht (s. o.). Aber auch die Notwendigkeit für new besteht überhaupt nicht. Was hast Du gegen den ARP?
    „Meine Komplikation hatte eine Komplikation.“