IBOutlet @property

  • IBOutlet @property

    Ich habe neulich in einem Cocoa-Lehrbuch gelesen, dass bei IBOutlets @property definiert werden.
    Stutzig geworden habe ich dann mal Apples Dokument zum Speichermanagement durchgestöbert : siehe da, hier steht es auch.
    Und zwar soll man bei Mac OS X die Eigenschaft "assign" verwenden.
    Das ganze wird irgendwie noch erklärt, verstanden hab ichs aber nicht.

    Bei meinen bisherigen Programmen habe ich noch nie properties für IBOutlets gesetzt.

    Was ist denn - in einfachen Worten - der Hintergrund / tiefere Sinn dafür?
    Anders herum gefragt : wenn ich diese nicht definiere, geht dann irgendwas schief?

    Hans

  • Eine Property macht ja nichts anderes als Dir die Arbeit abzunehmen selber Getter und Setter zu schreiben. Wenn Du Deine Getter und Setter selber sauber implementierst, dann brauchst du auch keine Properties.

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

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

  • Wenn man das nicht tut geht auch nichts schief. Wohin man nun das 'IBOutlet' schreibt macht keinen Unterschied, der Compiler ignoriert das sowieso. Das ist einzig dafür da, dem Interface Builder mitzuteilen, welche Outlets verfügbar sind. Beim Laden des NIBs werden die dann über KVC gesetzt, was automatisch den entsprechenden Setter (der z.B. auch synthetisiert sein kann) verwendet. Und wenn es keinen Setter gibt greift KVC direkt auf die Ivars zu. Bei Assign-Properties macht das keinen Unterschied.

  • HansGerber schrieb:

    Ich habe neulich in einem Cocoa-Lehrbuch gelesen, dass bei IBOutlets @property definiert werden.
    Stutzig geworden habe ich dann mal Apples Dokument zum Speichermanagement durchgestöbert : siehe da, hier steht es auch.
    Und zwar soll man bei Mac OS X die Eigenschaft "assign" verwenden.
    Das ganze wird irgendwie noch erklärt, verstanden hab ichs aber nicht.

    Bei meinen bisherigen Programmen habe ich noch nie properties für IBOutlets gesetzt.

    Was ist denn - in einfachen Worten - der Hintergrund / tiefere Sinn dafür?
    Anders herum gefragt : wenn ich diese nicht definiere, geht dann irgendwas schief?

    Hans

    Apple hat das Speichermanagement von Nibs entgegen den allgemeinen Regeln versaut. Es gibt da ein retain zu viel. Um das wieder auszugleichen, musst du bei IBOutlet ein assign verwenden, also ein retain gegen die Regeln weniger.

    Ganz einfach gesagt: Das mit dem Outlet verwiesene Objekt gehört dir nicht. Es gehört demjenigen, der den Nib geladen hat.
    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"?

  • Spricht denn was dagegen den IBOUTLET mit einem retain property zu machen und dann im dealloc einen release? Ausser das man mehr Tippen muss ? Zumindest ist man dann auch owner und das ist ja nicht falsch wenn man darauf zugreift im code, oder ?

    Gruß

    Claus
    2 Stunden Try & Error erspart 10 Minuten Handbuchlesen.

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

  • Thallius schrieb:

    Spricht denn was dagegen den IBOUTLET mit einem retain property zu machen und dann im dealloc einen release? Ausser das man mehr Tippen muss ? Zumindest ist man dann auch owner und das ist ja nicht falsch wenn man darauf zugreift im code, oder ?

    Gruß

    Claus


    Was sollte dann dafür sprechen, außer dass Du tippen möchtest?
    I would be embarrassed if they did not spy on me.

  • Amin Negm-Awad schrieb:

    Apple hat das Speichermanagement von Nibs entgegen den allgemeinen Regeln versaut. Es gibt da ein retain zu viel. Um das wieder auszugleichen, musst du bei IBOutlet ein assign verwenden, also ein retain gegen die Regeln weniger.

    Es beruhigt mich, dass Du das auch so siehst. Ich dachte schon, ich hätte die versteckte Großartigkeit des Konzeptes nicht verstanden und wäre der einzige, der das Ganze, besonders beim Aufräumen von geladenen nibs, einfach nur Käse findet.
    Multigrad - 360°-Produktfotografie für den Mac

  • Thallius schrieb:

    Spricht denn was dagegen den IBOUTLET mit einem retain property zu machen und dann im dealloc einen release? Ausser das man mehr Tippen muss ? Zumindest ist man dann auch owner und das ist ja nicht falsch wenn man darauf zugreift im code, oder ?

    Ich hab' mir so schon einige Male retain cycles eingehandelt. Das spricht zumindest für mich dagegen.
    Multigrad - 360°-Produktfotografie für den Mac

  • Thallius schrieb:

    Spricht denn was dagegen den IBOUTLET mit einem retain property zu machen und dann im dealloc einen release? Ausser das man mehr Tippen muss ? Zumindest ist man dann auch owner und das ist ja nicht falsch wenn man darauf zugreift im code, oder ?

    Gruß

    Claus

    Mein Fehler, falsche Erinnerung.

    Das Problem lag nicht im assign. Das ist richtig, weil du sonst Retainzyklen bekommen kannst.

    Aus der Erinnerung das Problem:

    Einige Methoden laden einen Nib mit den TLO außerhalb des ARP. Die wurden dann doppelt gehalten, wenn du sie dir geholt hast. Also musstest du durch das gesamte Array hangeln und jedem ein autorelease schicken. Nimmst du sie nicht an, hast du aber keine Möglichkeiten, an die TLO zu kommen. Zwischenzeitlich ist das aber unproblematisch, da NSWindowController et al. gibt.
    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"?

  • mattik schrieb:

    Amin Negm-Awad schrieb:

    Apple hat das Speichermanagement von Nibs entgegen den allgemeinen Regeln versaut. Es gibt da ein retain zu viel. Um das wieder auszugleichen, musst du bei IBOutlet ein assign verwenden, also ein retain gegen die Regeln weniger.

    Es beruhigt mich, dass Du das auch so siehst. Ich dachte schon, ich hätte die versteckte Großartigkeit des Konzeptes nicht verstanden und wäre der einzige, der das Ganze, besonders beim Aufräumen von geladenen nibs, einfach nur Käse findet.

    Ja, wobei ich das allerdings falsch verortet hatte. Es geht in der Tat um das Aufräumen auch ohne IBOutlet.

    Ich glaube, Apple ging ursprünglich davon aus, dass einmal geladene Nibs nicht mehr entladen werden. Es gibt auch Stellen in der Doku, in der das anklingt. Mit zunehmender Komplexität ist es aber natürlich sinnvoll, etwa das EInstellungsfenster oder Infofenster auch wieder zu entladen.
    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:

    mattik schrieb:

    Amin Negm-Awad schrieb:

    Apple hat das Speichermanagement von Nibs entgegen den allgemeinen Regeln versaut. Es gibt da ein retain zu viel. Um das wieder auszugleichen, musst du bei IBOutlet ein assign verwenden, also ein retain gegen die Regeln weniger.

    Es beruhigt mich, dass Du das auch so siehst. Ich dachte schon, ich hätte die versteckte Großartigkeit des Konzeptes nicht verstanden und wäre der einzige, der das Ganze, besonders beim Aufräumen von geladenen nibs, einfach nur Käse findet.

    Ja, wobei ich das allerdings falsch verortet hatte. Es geht in der Tat um das Aufräumen auch ohne IBOutlet.

    Ich glaube, Apple ging ursprünglich davon aus, dass einmal geladene Nibs nicht mehr entladen werden. Es gibt auch Stellen in der Doku, in der das anklingt. Mit zunehmender Komplexität ist es aber natürlich sinnvoll, etwa das EInstellungsfenster oder Infofenster auch wieder zu entladen.


    Das war tatsächlich mal richtig so. Entladen, wozu, wenn man ein swapfile hat.
    Das ganze nib-Konzept ist einfach hornalt. Der IB hat bald das Silberne, wenn ich das richtig sehe.
    I would be embarrassed if they did not spy on me.