Wie zeige ich ein Bild in NSView an ?

Bei benannten Bildern kann man eigentlich davon ausgehen.

Aber die Konstruktion ist dennoch nicht zu empfehlen, weil man dabei auf einen echten Setter für das Bild verzichtet.
Außerdem bin ich mir bei der Nachricht von Objcler nicht ganz sicher, ob die Ironiefahne oben war…

Man braucht halt nicht immer einen Setter (das hatte ich mit dem halben Grundstein gemeint). Und ich hoffe, dass Objcler seine Ironiefahne nicht ausgeklappt hat, denn mein Vorschlag weiter oben laeuft ja auf dasselbe hinaus.

PS: Ich liebe es, Caches zu cachen. Ich trau' dem NSImage-eigenen Cache naemlich nur bedingt; aussdem find' ich's so uebersichtlicher und bin schlicht ein gluecklicherer Mensch, wenn ich nicht das Gefuehl (der tatsaechliche Zeitverlust wird vernachlaessigbar sein, aber ich bin halt emotional) habe, Zeit dabei zu verlieren, wenn jedes mal ein NSDictionary o.ae. durchsucht wird.

Original von Tom9811
Es wird ja vom System gecached. Und wenn du es dir lokal noch einmal anlegst, hast du jetzt den Cache des Cache.

Man müsst es drauf ankommen lassen …

Genau. Wieder wird hier der Fehler gemacht etwas optimieren zu wollen, was schon optimiert ist. NSImage hat einen internen Cache. Daher jedes mal neu erzeugen und am Ende das View bzw. die ganze Anwendung auf Performance testen. Dann kann man noch immer hier und da eigene Caches einbauen.

Das war keine Ironie. Ich praktiziere das täglich.

Falls die Konstruktion des Bildes zu kompliziert ist lagere ich dies in eine Methode aus. Das sieht dann so aus:



Und dann schaue ich mir am ENDE des Entwicklungsprozesses an, ob die Methode __segmentedImage überhaupt einen großen Einfluss auf die Performance hat.

@long
Der Setter ist eine Folge, nicht die Ursache. Man verzichtet nicht auf ihn, sondern benötigt ihn dann nicht.

@Peter
Ich glaube, dass das Durchsuchen in dem Dictionary ein Vergleich auf einen Hash ist. Das dürfte überschaubar sein.

Objective-C 2 hin oder her: An so etwas wie
self.__segmentedImage
kann ich mich einfach nicht gewöhnen.

Original von Tom9811
Objective-C 2 hin oder her: An so etwas wie
self.__segmentedImage
kann ich mich einfach nicht gewöhnen.

Ich schon.

Original von wolf_10de
Für die nächste Auflage wirst Du es wohl müssen

Warum müssen?
Welche Syntax Du nutzt ist wurscht, das ins Vorwort, alte Syntax nutzen und gut is.

Neee, neee, das ist schon beschlossen: Bis einschließlich Speicherverwaltung läuft das Parallel. Wenn die Accessoren erklärt sind, und was die tun, wird nur noch dot, @property und @synthesize verwendet.

Es sind wohl die beiden Unterzüge, die mich etwas WAHNSINNIG machen.

Original von Tom9811
Neee, neee, das ist schon beschlossen: Bis einschließlich Speicherverwaltung läuft das Parallel. Wenn die Accessoren erklärt sind, und was die tun, wird nur noch dot, @property und @synthesize verwendet.

Es sind wohl die beiden Unterzüge, die mich etwas WAHNSINNIG machen.

"_" ist verboten. "pSegmentedIndex" finde ich doof - das stört den Lesefluss und bei manchen Variablennamen - zB. bei "immel" kommt ein "p" davor nicht so gut. Daher "__"

Original von Objcler

Original von Tom9811
Neee, neee, das ist schon beschlossen: Bis einschließlich Speicherverwaltung läuft das Parallel. Wenn die Accessoren erklärt sind, und was die tun, wird nur noch dot, @property und @synthesize verwendet.

Es sind wohl die beiden Unterzüge, die mich etwas WAHNSINNIG machen.

"_" ist verboten. "pSegmentedIndex" finde ich doof - das stört den Lesefluss und bei manchen Variablennamen - zB. bei "immel" kommt ein "p" davor nicht so gut. Daher "__"

Na ja, es gäbe ja noch segmentedImage …

Übrigens ist __ ganz formal auch verboten.

Original von Tom9811

Original von Objcler

Original von Tom9811
Neee, neee, das ist schon beschlossen: Bis einschließlich Speicherverwaltung läuft das Parallel. Wenn die Accessoren erklärt sind, und was die tun, wird nur noch dot, @property und @synthesize verwendet.

Es sind wohl die beiden Unterzüge, die mich etwas WAHNSINNIG machen.

"_" ist verboten. "pSegmentedIndex" finde ich doof - das stört den Lesefluss und bei manchen Variablennamen - zB. bei "immel" kommt ein "p" davor nicht so gut. Daher "__"

Na ja, es gäbe ja noch segmentedImage …

Übrigens ist __ ganz formal auch verboten.

Bei "segmentedImage" kann aber nicht auf den ersten Blick zwischen "privater" und "öffentlicher" Eigenschaft unterschieden werden. Das Bild wird da nur zu internen Zwecken benötigt. Daher ist es ja auch in einer Category. KVO/KVC funktioniert ja auch mit dem "__" Prefix.

Was spräche dagegen auf jeden Prefix zu verzichten bis auf die Tatsache, dass die Unterscheidungfähigkeit auf den ersten Blick wegfällt? Nichts. Geschmackssache

Na ja, es ist die Frage, ob dich beim Abholen interessiert (und dann: interessieren darf), ob es eine private Methode ist. Würde sich etwas ändern, wenn es eine öffentliche Methode wäre?

Original von Tom9811
Na ja, es ist die Frage, ob dich beim Abholen interessiert (und dann: interessieren darf), ob es eine private Methode ist. Würde sich etwas ändern, wenn es eine öffentliche Methode wäre?

Naja. Dinge, die ich nur intern brauche gehören einfach nicht in eine öffentliche Schnittstelle. Diese sollte minimal und komplett sein. Würde ich jede kleine Helferfunktion öffentlich machen würde das die öffentliche Schnittstelle total aufblähen.

Original von Objcler

Original von Tom9811
Na ja, es ist die Frage, ob dich beim Abholen interessiert (und dann: interessieren darf), ob es eine private Methode ist. Würde sich etwas ändern, wenn es eine öffentliche Methode wäre?

Naja. Dinge, die ich nur intern brauche gehören einfach nicht in eine öffentliche Schnittstelle. Diese sollte minimal und komplett sein. Würde ich jede kleine Helferfunktion öffentlich machen würde das die öffentliche Schnittstelle total aufblähen.

Das ist richtig. Ich legte dir ja auch nicht nahe, es öffentlich zu machen, um Gottes Willen!

Aber wieso musst du bei der Namenswahl darauf eingehen? Also, was ich meine:

- Lege sie in deine private Kategorie, wenn sie privat ist.
- Lege sie in den öffentlichen Header, wenn sie öffentlich ist.
- Nenne sie in jedem Falle segmentedImage.

Original von Tom9811

Original von Objcler

Original von Tom9811
Na ja, es ist die Frage, ob dich beim Abholen interessiert (und dann: interessieren darf), ob es eine private Methode ist. Würde sich etwas ändern, wenn es eine öffentliche Methode wäre?

Naja. Dinge, die ich nur intern brauche gehören einfach nicht in eine öffentliche Schnittstelle. Diese sollte minimal und komplett sein. Würde ich jede kleine Helferfunktion öffentlich machen würde das die öffentliche Schnittstelle total aufblähen.

Das ist richtig. Ich legte dir ja auch nicht nahe, es öffentlich zu machen, um Gottes Willen!

Aber wieso musst du bei der Namenswahl darauf eingehen? Also, was ich meine:

- Lege sie in deine private Kategorie, wenn sie privat ist.
- Lege sie in den öffentlichen Header, wenn sie öffentlich ist.
- Nenne sie in jedem Falle segmentedImage.

Nun gut.

Original von Tom9811
- Nenne sie in jedem Falle segmentedImage.

Da kann ich nur zustimmen. Es hat sich mir noch nie erschlossen, wofür der Unterstrich hier gut ist. Das bedeutet ja, dass 'segmentedImage' und '_segmentedImage' zusammen verwendet sollen, was im Endeffekt nur die Verwirrung erhöht.

Es geht hier ja nicht um Instanzvariablen, sondern Methoden. Es ist aber schon eine stille Konvention, private Methoden (oder Funktionen) mit einem Unterzug zu beginnen. Nur gibt es gerade bei den Methoden dazu eigentlich keinen rechten Grund.