(Einsteiger-) Fragen ohne Zusammenhang

a) Nein, im -awakeFromNib müssen die Objekte bereits initialisiert sein, auch die nicht persistenten Instanzvariablen. Außerdem weißt du nicht, ob du aus einem Nib kommst oder nicht.

b) Das ist mir bekannt. Sie sagen es aber nicht an der Stelle, an der es um Initialisierung geht. Und zwar der generellen Initialisierung innerhalb von Objective-C. Es ist ja schön ein grundlegendes Dokument zu haben, welches mit langen Erläuterungen eine eherne Regel aufstellt, wenn dann irgendwo anders im Dickich ohne Hinweis bei den Grundlagen etwas anderes gemacht wird. Dann muss man zumindest mmall dranschreiben: Ach, übrigens, beim Coding kann das anders sein.

c) Wieso möchtest du das nicht?

Zu a)
Nun ja, ich weiß aber schon, ob meine Klasse aus einem Nib per -initWithCoder: erzeugt wird oder nicht, denn dafür muss ich ja eine IB Palette schreiben, sonst kann ich ein Objekt ja gar nicht voll initialisiert im Nib ablegen. D.h. Du must die -encodeWithCoder: Methode sowieso entsprechend implementieren.

Zu b)
Die -initWithCoder: Methode kommt übrigens aus dem NSCoding-Protokoll und daher kann man sie auch nicht einfach mit den anderen init-Methoden in einen Topf werfen. Sie hat halt eine ganz spezielle Aufgabe, nämlich ein Objekt aus archivierten Daten zu initialisieren.

Zu c)
Na ja, ich fände eine Objekterzeugung wie zum Beispiel sowas
doch ein wenig unhandlich. Und das ist noch nicht einmal alles, was man an einem NSButton so einstellen kann. So ein Ding für NSTableView oder NSTextView mag ich mir gar nicht erst vorstellen.

Michael

a) Ich muss gerade in den Fällen der Ableitung keine Palette schreiben. Aber davon unabhängig muss ich nicht zweimal dden gleichen Code im dI und im -initWithCoder: haben. Wieso sollte ich das müssen. Das führt nur zu Wartungsproblemen.

b) Jeder -init… hat eine ganz spezielle Aufgabe, sonst gäbe es ihn ja nicht. Ich sagte ja schon: Meinetwegen sollte man es halten wie der Dachdecker, wobei ich das unpüraktisch finde. Nur darf ich dann nicht die Regel aufstellen: "Immer den eigenen dI aufrufen" und mich dann später selber nicht daran halten. Gerade bei so einem allgemeinen Protokoll hätte es sich angeboten zu sagen: "Neben dem dI gibt es noch die Initialisierung aus einem Archiv. Hier läuft das anders."

c) Die Objekterzeugung ist nicht unhandllicher als der Aufruf der Setter für jeden Parameter. Der Decoder sieht dann so aus (natürlich mit decode-Aufrufen):

Wo liegt da der Vorteil?

Original von Tom9811
Im Übrigen entspricht es dem Konzept des designated Initalizers, welches nicht von mir, sondern von Apple stammt:
"Designated initializers are chained to each other through messages to super, while other initialization methods are chained to designated initializers through messages to self."
Und man kann ja schon erwarten, dass sich Apple an seine eigenen Regeln hält.

Ich habe mal überlegt, was passieren würde, wenn Apple es so machen würde, wie Du es Dir vorstellst.

-initWithCoder: ruft den designated Initializer auf, soweit gut.
Wie da oben steht ruft dieser den designated Initializer von super auf, auch noch gut.
-initWithCoder: ruft -initWithCoder: von super auf, damit auch super seinen Kram dekodieren kann!
-initWithCoder von super ruft dann den eingenen designated Initializer auf, aber halt, der wurde bereits schon einmal durch die Subklasse aufgerufen.

Nein, das geht so gar nicht.

Michael

Original von Tom9811
c) Die Objekterzeugung ist nicht unhandllicher als der Aufruf der Setter für jeden Parameter.
[...]
Wo liegt da der Vorteil?

Der Vorteil liegt in der Vererbung. In meiner Subklasse muss ich nur selbst definierten Parameter setzen. Die geerbten Parameter lasse ich von der -initWithCoder: Methode der Superklasse setzen. Einem allumfassenden Initializier müsste ich aber ausnahmslos alles übergeben.

Michael

Der dI muss nicht allumfassend sein. Das finde ich positiv, hat aber mit diesem Problem nichts zu tun. Du sollst nur das, was der dI nimmt, sei es viel, sei es wenig, anstatt mit Settern zu setzen mit ihm setzen.

Das erspart dir doppelte Logik. Doppelte Logik ist fehleranfällig.

Und wie gesagt: Man kann es ja noch halten wie der Dachdecker, auch wenn ich es nicht gut finde. Aber dann darf man eben nicht eine abweichende allgemeine Regel sprechen und Wasser trinken.

Wenn es Apple so machen würde, wie ich es mir vorstelle, würde in der Doku stehen:"Die Initialisierung beim Decoding funktioneirt übrigens anders." Es wäre auch schon dienlich, wenn der Decoder einfach nicht -initWithCoder: heißen würde. Dann käme man nämlich nicht auf den Gedanken, dass er sich nicht an diie Initialisierungregeln hält.

Aber das Problem im Initialisierungsablauf sehe ich in der Tat. In der Tat ist es einem Initialisierer verboten einen Initialisierer der Superklasse aufzurufen, es sei denn dI den di(super). Auch so eine "eherne Regel" von Apple. Ein weiteres Argument, es so nicht zu machen. (Das ist übrigens einer der Gründe, warum das Apple verbietet.)

Das wäre unpraktisch, ohne jeden Zweifel. Deshalb sollte man dann eben den Decoder ganz aus der Initialisierunjg herausnehmen. Ihn nicht Initializer nennen, ihn nicht -init nennen usw. Kein Mensch würde sich mehr vertun. Dieses Thema haben wir ja heute wahrlich nnicht zum ersten Male.

Wenn der dI nicht allumfassend sein muss, hast Du ja wieder das ursprüngliche doppelte Setzen von Parametern. Erst mit Standardwerten per dI und dann mit den Werten aus dem Archiv. Dazu dann noch das doppelte Aufrufen der dI der Superklassen -> Verschlimmbesserung hoch 2.

Man kann auch einfach -initWithCoder: als designated Initializer für archivierte Objekte ansehen und schon stimmt Apples Regel wieder zu 100%. :]

Michael

An eine Ausrede-Lösungmit einem Schatten-DI habe ich auch schon gedacht. Nur steht das nun wirklich nirgendwo. Im Übrigen vermittelt die Doku mindestens dein Eindruck, dass es stets einen dI pro Klasse gibt. Aber auch diese Regel wird ja ohnehin nicht durchgehalten, siehe etwa NSCell.

Nochmal: Man kann das ja halten wie der Dachdecker. Aber ein Hinweis in der Objective-C-Doku wäre notwendig. Das ist wie gesagt nicht der erste Thread zu diesem Thema.

Wenn Du die Einstellungen über NSUserDefaults verwaltest, ist das nicht möglich, denn sobald Du Änderungen an den Standard User Defaults vornimmst, musst du davon ausgehen, dass diese auf Platte geschrieben werden. Das geschieht nämlich in regelmäßigen Abständen automatisch.

Was Du vorhast, kannst Du durch Verwendung von NSUserDefaultsController erreichen. Den kann man so konfigurieren, dass Änderungen nicht sofort gespeichert werden und bietet auch eine -revert: Methode an.

Michael

iTunes beenden und neu starten. Nur, was willst Du damit bezwecken?

Michael