Posen & Co.

  • Posen & Co.

    Servus.

    Ich woll euch mal von einer sehr komischen Erfahrung berichen, die ich letztens gemacht hab:

    Aus speziellen Gründen war ich gezwungen, ein paar interne Klassen aus dem AppKit Framework zu erweitern. Vielleicht kennt sich ja einer mit dem undo des Textsystems aus, das waren konkret NSUndoTextOperation, NSUndoReplaceCharacters, NSUndoTyping und NSUndoSetAttributes. Ich hab diese Klassen also abgeleitet und hann mit poseAsClass: die Subclasses dazwischen geschoben.

    Das hat auch alles ganz wunderbar geklappt, allerings: es gab absolut willkürliche crashes in unterschiedlichen zeitlichen Abständen an absolut willkürlichen Orten (z.B. im erstellen eines Dicts, laden eines nibs, zeichnen eines views usw), und zwar immer beim alloziieren von Speicher. Ich hab alles versucht, bin erst nicht drauf gekommen, dass es mit dem Posen zu tun haben könnte und so weiter.

    Nach unendlich viel Zeit (3 Wochen oder so) hab ich's dann durch Zufall rausgefunden: Es lag daran, dass ich von den Klassen, die ich überschrieben hatte nur die Funktionen in mein Interface geschrieben habe und nicht auch noch die Variablen. Hier mal n kleines snippet, erst halt ohne die Variablen:

    Quellcode

    1. @interface NSUndoTextOperation : NSObject
    2. {
    3. struct _NSRange _affectedRange;
    4. NSUndoManager *_undoManager;
    5. NSLayoutManager *_layoutManager;
    6. }
    8. - (id)initWithAffectedRange:(NSRange)affectedRange layoutManager:(NSLayoutManager *)layoutManager undoManager:(NSUndoManager *)undoManager;
    10. - (void)undoRedo:(id)sender;
    12. - (NSTextView *)firstTextViewForTextStorage:(NSTextStorage *)storage;
    13. - (NSUndoManager *)undoManager;
    15. - (BOOL)isSupportingCoalescing;
    17. @end
    19. @interface _NSUndoTextOperation : NSUndoTextOperation
    20. @end
    Alles anzeigen


    Es müssen also im *Interface* alle Variablen der zu überposenden klasse bekannt sein. Dass man keine hinzufügen kann ist mir klar, aber vielleicht kann mir einer der Obj-C geeks sagen, warum die bekannt sein müssen? Wird die größe der Klasse nicht zu Laufzeit, sondern schon beim Compilieren ermittelt?

    grüße,

    Max

  • RE: Posen & Co.

    Ich verstehe dich nicht ganz. Du kannst als Superklasse posieren. Du hast dann aber automatisch lle Member der Superklasse.

    In deinem Code ist die Superklasse allerdings NSObject. Wolltest du als NSObject posieren?

    +++
    Argh, ich habe dich wohl falsch verstanden. _NSUndo… sollte als NSUndo… posieren?
    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"?

  • RE: Posen & Co.

    Hat er ja auch nicht. Wenn ich's richtig verstanden habe, wollte Max NSUndoTextOperation durch seine eigene Klasse ersetzen. Also: Abgeleitet, per poseAsClass: ersetzt. Da aber NSUndoTextOperation AppKit-intern ist, wird die Klasse in keinem Header defininiert - er kann also nicht kompilieren, weil man nichts von etwas Unbekanntem ableiten kann. Also kurzerhand selbst ein NSUndoTextOperation definiert - mit den Instanzvariablen, die er braucht - so sind beim Kompilieren alle Symbole definiert. Max, habe ich das so richtig verstanden?

    Wenn das so ist, dann liegt der Hase nicht beim poseAsClass: im Pfeffer: Deine Klassendefinition von NSUndoTextOperation kollidiert schlicht mit der im Framework. Beispielsweise hätte bei Dir die Instanzvariable _affectedRange einen Offset von 0 zur Objektbasis - das ist in Apples Binary nicht unbedingt so (sogar höchstwahrscheinlich nicht). Wenn Du auf _affectedRange zugreifst, liest Du irgendwas anderes und überschreibst munter andere Instanzvariablen, nämlich die, die Apple dort hat. Dass das über kurz oder lang zu beliebigen Crashes führt, wundert mich nicht wirklich.

    Das Ableiten von privaten Klassen ist m.E. grundsätzlich keine gute Idee. Dazu bräuchtest Du zumindest korrekte Header von NSUndoTextOperation (und allen Oberklassen). Außerdem: Wer weiß, was Apple mit seinen Instanzvariablen so anstellt und wie die Mechanismen darin sonst so aussehen? Apple behält sich bei solchen Klassen vor, die Implementierung bei Updates beliebig zu ändern, was Dein Programm unbrauchbar machen würde. Oder liege ich hier komplett daneben? Korrigiert mich bitte, wenn ich Mist erzähle...

    Das muss irgendwie anders gehen - weshalb war das für Dich unerlässlich?
    Multigrad - 360°-Produktfotografie für den Mac

  • RE: Posen & Co.

    Die Doku sagt:
    The receiver must be defined as a subclass of aClass. It can’t declare any new instance variables of its own, but it can define new methods and override methods defined in aClass.

    D.h. man darf nicht einfach eine Subclass von NSObject posen.

    Vielleicht reicht ja auch eine Category. Posing braucht man eigentlich nur dann, wenn man eine vorhandene Methode unter gleichem Namen erweitern will. Bei Categories kann man eine schon definierte Methode gleichen namens ja nicht aufrufen ([super method] sucht in der Superklasse).

    Neue Instanzvariablen hinzufügen ist sehr tricky. Ein Weg ist manchmal ein NSMutableDictionary mit self als Key einzuführen. Und damit jeder Instanz ein weiteres Objekt mit neuen Variablen mitzugeben.

    -- hns

  • RE: Posen & Co.

    Original von mattik
    Max, habe ich das so richtig verstanden?


    Wenn das so ist, dann liegt der Hase nicht beim poseAsClass: im Pfeffer: Deine Klassendefinition von NSUndoTextOperation kollidiert schlicht mit der im Framework.

    Nein, nein. Das ist schon so richtig. Ich hab mir die Klassendefinition ja mit Class-Dump aus dem Framework geholt. Und selbst ohne Variablen-Deklaration geht es ja super. Das interessante ist nur, wenn ich die Klasse in meinem Code bekannt mache (das macht das interface, ich definiere sie ja nicht - dafür braucht es eine Implementation), dann muss ich auch ihre Variablen bekannt machen, sonst funktioniert das posen nicht. Bzw. Es funktioniert halt schon, allerdings gibt es ein leck im speicher und es kollidiert...

    Das Ableiten von privaten Klassen ist m.E. grundsätzlich keine gute Idee. Dazu bräuchtest Du zumindest korrekte Header von NSUndoTextOperation (und allen Oberklassen).

    Dafür gibt es das herrliche Programm Class-Dump: Klick mich

    Außerdem: Wer weiß, was Apple mit seinen Instanzvariablen so anstellt und wie die Mechanismen darin sonst so aussehen?

    Das kann man ja durch verschiedene Mittel rausbekommen. Zumindest annährungsweise. Parameter angucken, Laufzeitanalyse, Klassenheader von verwendeten Klassen. AUßerdem brauch ich die Variablen in meiner Subklasse nicht, ich optimiere nur ein Problem, s.u.

    Oder liege ich hier komplett daneben? Korrigiert mich bitte, wenn ich Mist erzähle...

    Grundsätzlich ist es nicht falsch :)

    Das muss irgendwie anders gehen - weshalb war das für Dich unerlässlich?

    Die einzige Alternative wäre ein komplettes Rewrite des Undos im TextSystem gewesen. Das allerdings wäre nicht nur extrem aufwändig gewesen (ich sage nur Action Coalescing), sondern hätte überschreibungen von privaten Methoden in bekannten Klassen benötigt. So habe ich nur 4* vier Zeilen code.

    Kurz die Erläuterumng des Problems: Mein Programm het mehrere Interfaces, die über Module geladen werden. Dabei wird der selbe Inhalt (Text) immer "nur" (optisch) anders aufbereitet dargestellt. Das Problem ist, dass das TextSystem das Undo an den LayoutManager hängt. Das heißt, dass der LayoutManager gemerkt wird und über hin wird der zu verämndernde TextSTorage ermittelt. Zum einen habe ich ein Text-Distribution-System, was falsche Ergebnisse für die Ermittlung des TextStorages liefert, zum anderen ist nach einem Wechsel des Interfaces der LayoutManager nicht mehr vorhanden, was zu einem Problem führt. Entweder die App crasht oder man löscht das Undo. Beides ist mist ;) Also war die einzige Möglichkeit, sich in die internen Methoden der internen Klassen zu hängen und die falschen informationen zu korrigieren. Hat ne weile gedauert, bis ichs gefunden hatte, aber jetzt ist's super-einfach:

    Quellcode

    1. - (void)undoRedo:(id)target
    2. {
    3. if ([[self undoManager] isKindOfClass: [DistributingUndoManager class]])
    4. [super undoRedo: [(DistributingUndoManager *)[self undoManager] textStorage]];
    5. else
    6. [super undoRedo: target];
    7. }


    Meine eigentliche Frage war: wieso müssen beim Posen die Instanzvariablen bekannt sein und warum reicht nicht der Klassenname.

    gruß
    Max

  • RE: Posen & Co.

    Original von hns
    Die Doku sagt:
    The receiver must be defined as a subclass of aClass. It can’t declare any new instance variables of its own, but it can define new methods and override methods defined in aClass.

    D.h. man darf nicht einfach eine Subclass von NSObject posen.

    Das ist klar. Aber warum müssen die Instanzvariablen der Superklasse bekannt sein? Und warum gibt es sonst Speicherprobleme.

    Vielleicht reicht ja auch eine Category

    Nein. leider eben nicht. Ich muss ein Verhalten der supermethode verändern, deshalb muss ich auch exakt diesen Aufruf abfangen.

    Neue Instanzvariablen hinzufügen ist sehr tricky. Ein Weg ist manchmal ein NSMutableDictionary mit self als Key einzuführen. Und damit jeder Instanz ein weiteres Objekt mit neuen Variablen mitzugeben.

    Es gibt sogar eine noch elegantere Lösung - static Variablen:

    Quellcode

    1. - (id)object:(id)obj
    2. {
    3. static id object = nil;
    5. if (obj)
    6. object = obj;
    8. return object;
    9. }


    Max

  • RE: Posen & Co.

    Ok, wenn es so ist, dann ist das in der Tat der Fehler nicht das Posieren ansich.

    Ich sehe das auch so, dass das Ableiten von unbekkannten Klassen nicht der Bringer ist. Das ändert sich auch nicht dadurch, dass man dann posiert. Das muss zu Ärger führen.
    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"?

  • RE: Posen & Co.

    Zur Laufzeit besteht ja eine isa-Struktur, also die Klassenbeschreibung. Diese Struktur wird von dem Compiler erzeugt. Wenn der Compiler nichts davon w2eiß, wird es früher oder später Codefragmente geben, die nicht zur Laufzeitstruktur passen.

    Man könnte das sicher verhindern, indem man den Compiler verändert. ;)
    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"?

  • RE: Posen & Co.

    Was du feststellst, ist die Laufzeitstruktur. Du unternimmst jetzt den Versuch, diese in deine Source zurückzubilden. Letztlich ist das ein Fall von Dekompilierung oder reverse Engineering.

    Das Problem ist nicht einfach ein Leck. Deine Strukturen passen nicht. Noch schlimmer wird das Ganze, wenn man bedenkt, dass grundsätzlich und sehr, sehr vorsichtig Änderungen in der Laufzeitstruktur gemacht werden können. Dazu muss man aber die RTE komplett verstanden haben und kennen. Das ist nichht trivial.

    Eine Aussage wie "das funktioniert" aber doch ist da sehr, sehr, sehr dünnes Eis.

    Zum eigentlichen Problem (Warum das mit Posieren nicht geht, jedenfalls nicht sicher, dürfte jetzt klar sein):

    Wenn du nur das Aussehen ändern willst, verstehe ich nicht ganz, wieso du einen neuen Layout-Manager benötigst. Ich verstehe dich doch richtig, dass der Text ansich (also der Storage) glleich bleibt, sondern nur ein anderes Interface übergestülpt wird!? Wie belässt du den Layout-Manager nicht als Layou-Manager wie er ist?

    Das Undoing ist eine Sache des Controllers und des Models. Deshalb ist es ja auch in den Klassen Storage und Layout-Manager implementiert. Das Aussehen ist eine Sache der Views, welche in Container und TextView implementiert sind. Eigentlich sollte sich das gar nicht beeinflussen.

    Andernfalls, wenn das aus irgendwelchen Gründen erforderlich ist, wäre es dann nicht wes3entlich einfacher, den Layout-Manager abzuleiten?
    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"?

  • RE: Posen & Co.

    Original von M.A.X
    Das ist klar. Aber warum müssen die Instanzvariablen der Superklasse bekannt sein? Und warum gibt es sonst Speicherprobleme.
    Weil das eigentliche struct in dem die Instanzvariablen gespeichert werden sich aus allen Instanzvariablen aller Superklassen und der eigentlichen zusammensetzen. Beispiel:

    Quellcode

    1. @interface A : NSObject
    2. {
    3. int x;
    4. }
    6. @interface B : A
    7. {
    8. int y;
    9. }
    11. =>
    12. struct B
    13. {
    14. // hier gibts evtl. noch interne Dinge von NSObject, z.B. refCount
    15. int x;
    16. int y;
    17. }
    Alles anzeigen
    D.h. wenn Du irgendwo das Interface von B nachbilden willst - aber direkt von NSObject abgeleitet - dann müssen auch alle ererbten Variablen in der richtigen Reihenfolge und Typ deklariert werden. Sonst passen die relativen Adressen nicht zusammen.

    -- hns

  • RE: Posen & Co.

    Original von Tom9811
    Was du feststellst, ist die Laufzeitstruktur. Du unternimmst jetzt den Versuch, diese in deine Source zurückzubilden. Letztlich ist das ein Fall von Dekompilierung oder reverse Engineering.

    naja, ich suche halt nur infiormationen raus. Da wird nichts wirklich dekompiliert...

    Das Problem ist nicht einfach ein Leck. Deine Strukturen passen nicht.

    Die passen schon, weil ich sie direkt aus dem Framework hab.

    Warum das mit Posieren nicht geht, jedenfalls nicht sicher, dürfte jetzt klar sein

    es geht sehr sicher. Es ist alles über die Klasse bekannt. Posieren ist eine ganz normale erweiterungstechnik. Das macht übrigens sogar apple so. Mit KVO, da wird auch eine subklasse erstellt, die alle methoden überschreibt, damit KVO messages gesendet werden können.

    Wenn du nur das Aussehen ändern willst, verstehe ich nicht ganz, wieso du einen neuen Layout-Manager benötigst.

    Tue ich ja gar nicht. Hab ich nicht gesagt.

    Ich verstehe dich doch richtig, dass der Text ansich (also der Storage) glleich bleibt, sondern nur ein anderes Interface übergestülpt wird!? Wie belässt du den Layout-Manager nicht als Layou-Manager wie er ist?

    Die interfaces sind eine komplette view-struktur, ggf. ganze fenster. Die Unterschiede kommen aus dem Storage. Der Text sieht anders aus. Was im einen Modus fett ist ist im anderen vielleicht grün. Das geht nur über dynamische Attribut-erzeugung aus einen distributions und notification-system. Deshalb brauche ich unterschiedliche storages.

    Das Undoing ist eine Sache des Controllers und des Models. Deshalb ist es ja auch in den Klassen Storage und Layout-Manager implementiert.

    Nicht ganz richtig: der LayoutManager hat überhaupt nichts mit dem Model zu tun.

    Das Aussehen ist eine Sache der Views, welche in Container und TextView implementiert sind. Eigentlich sollte sich das gar nicht beeinflussen.

    Zum einen tut es sich beim undo alles beeinflussen (selction, etc), zum anderen stimmt das auch nicht ganz. Z.B. fürhen weder container noch textView irgend eine art von zeichen durch. Das macht alles der Layout Manager. Der gehört eindeutig zum View. Und deshalb kann man auch verstehen, warum sich apple da dran hängt.

    Andernfalls, wenn das aus irgendwelchen Gründen erforderlich ist, wäre es dann nicht wesentlich einfacher, den Layout-Manager abzuleiten?

    Weil der LayoutManager irgendwann nicht mehr existiert?

  • RE: Posen & Co.

    Original von hnsD.h. wenn Du irgendwo das Interface von B nachbilden willst - aber direkt von NSObject abgeleitet - dann müssen auch alle ererbten Variablen in der richtigen Reihenfolge und Typ deklariert werden. Sonst passen die relativen Adressen nicht zusammen.

    Meine Klasse stammt direkt von NSObject ab. Und die Reihenfolge stimmt ja auch alles.
    Das ist eigentlich alles klar. Ich versuche die Frage *nochmal* anders:

    Wenn ich mich als eine Klasse pose, muss ich ja nur ein Interface haben. Was in dem Interface drin steht und wo es her kommt ist erstmal egal. Scheinbar funktioniert posen auch mit leeren Superklassen, aber das führt zu Abstürzen. Mein eigentliches Verständnisproblem liegt woanders: Das Posen passiert ganz offensichtlich zur Laufzeit. Das heißt, die Klasse kann eingeschoben werden, wann sie will. Des weiteren ist die zu überposende klasse aber bereits bekannt - sie kommt aus dem Framework - und wird ggf. sogar bereits benutzt. Es ist alles über sie bekannt, also auch Größe, Variablen, Methoden etc.

    -> Warum muss ich dann zur Kopilierungszeit alle Variablen der Klasse kennen/angeben, um sie zur Laufzeit korrekt zu überposen??

  • RE: Posen & Co.

    Dekompilieren bedeutet nicht zwingend, maschinell Dekompilieren. Und was du hast, ist ein Snapshot.

    es geht sehr sicher. Es ist alles über die Klasse bekannt. Posieren ist eine ganz normale erweiterungstechnik. Das macht übrigens sogar apple so. Mit KVO, da wird auch eine subklasse erstellt, die alle methoden überschreibt, damit KVO messages gesendet werden können.

    Die machen zur Laufzeit isa-Swizzling.

    Die interfaces sind eine komplette view-struktur, ggf. ganze fenster. Die Unterschiede kommen aus dem Storage. Der Text sieht anders aus. Was im einen Modus fett ist ist im anderen vielleicht grün. Das geht nur über dynamische Attribut-erzeugung aus einen distributions und notification-system. Deshalb brauche ich unterschiedliche storages.

    _Das_ scheint mir das Problem zu sein. Wenn etwas in der einen Sicht grün, in der anderen fett ist, sollte es im Storage (Model) _gleich_ stehen, nämllich als irgendein Attribut. Dein View sollte daraus grün bzw. fett machen.

    Nicht ganz richtig: der LayoutManager hat überhaupt nichts mit dem Model zu tun.

    Er liefert das Model. Wenn du also dort verbiegen möchtest, so hatte ich dich verstanden, dann kannst du den Layout-Manager ableiten und ihn eben den "neuen Storage" oder was du da hast, liefern lassen.

    Zum einen tut es sich beim undo alles beeinflussen (selction, etc),

    Ja und? Das Problem hast du stets. Nimmm den super-simplen Fall, dass du ein NSArray hast, daran zwei Controller und zwei Table-Views.

    Wird etwas eingefügt, so ändert sich die Selektion im Controller häufig genug. Dafür gibt es Attribute, um das Verhalten zu steuern.

    So ist es auch hier: Wenn sich der Text ändert, kannst du möglicherweise nicht mehr die Selektion halten. Der einfachste Fall ist es, dass du in dem einen View ein Wort selektiert hast, in dem anderen den gesamten Satz und dort dann löschst. Und? Das bekommmst du ja mit und kannst darauf reagieren, so wie es eben im obigen Parallelbeispiel der ArrayController macht.

    zum anderen stimmt das auch nicht ganz. Z.B. fürhen weder container noch textView irgend eine art von zeichen durch. Das macht alles der Layout Manager.

    Jein. Ob etwas ein View ist, lässt sich nicht mit der einfachen Frage beantworten, ob eiin Zeichnen durchgeführt wird. Das ist eine konzeptionelle Frage.

    Bei graphischen Apps, also solche, die irgendwie etwas Zeichenbares erzeugen ooder speichern, verschwindet der Unterschied. Auch hier wieder ein einfaches Beispiel: Du hast eine App, die irgendwelche Symbole zeichnen lässt. Diese Symbole werden etwa als Bezierpfad gespeichert oder selbige werden daraus erzeugt. Das ist eindeutig Model. Natürlich kann dann die entsprechende Symbolklasse auch gleich zeichnen. Das ändert nichts daran, dass sie Model ist.
    Schau dir etwa das Example Sketch an. Auch dort zeichnen sich die Modelklassen. Das ändert nichts an ihren Eigenschaften als Modelklassen.

    Der gehört eindeutig zum View.

    Nein, weil dein Kriterium kein taugliches Unterscheidungskriterium ist.
    Der Layout-Manager vermittelt zwischen Storage und View-System. Wenn man wirklich haarfein zwischen M-V-C aufblättern will, läge er wohl ziemlich genau beim Controller, nähe Model (dazwischen ist ohnehin häufig schwer zu unterscheiden, wie auch an der anderen Schnittstelle. Es gibt Leute, die sagen, dass man gar nicht Controller benötigt.)

    Und deshalb kann man auch verstehen, warum sich apple da dran hängt.

    Ich aber. :)

    Weil der LayoutManager irgendwann nicht mehr existiert?

    Wenn du ihn nicht als View begreifen würdest, dann würde er bei einem Wechsel des "Äußeren" weiter existieren …
    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"?

  • RE: Posen & Co.

    Original von Tom9811
    _Das_ scheint mir das Problem zu sein. Wenn etwas in der einen Sicht grün, in der anderen fett ist, sollte es im Storage (Model) _gleich_ stehen, nämllich als irgendein Attribut. Dein View sollte daraus grün bzw. fett machen.

    Grundsätzlich richtig, aber wie die meisten deiner Ansichten meilenweit von der Realität entfernt. Es lässt sich aus dem einfachen Grund nicht im View modifizieren, da der LayoutManager nur Attributeingaben aus dem TextStorage akzeptiert. Das ganze über temporäre Attribute zu machen, sowie jede andere lösung ist zu langsam. Meiostens muss man Kompromisse machen.

    Er liefert das Model. Wenn du also dort verbiegen möchtest, so hatte ich dich verstanden, dann kannst du den Layout-Manager ableiten und ihn eben den "neuen Storage" oder was du da hast, liefern lassen.

    er liefert es, aber wenn nichts mehr da ist, dann kann auch nichts mehr liefern.

    Jein. Ob etwas ein View ist, lässt sich nicht mit der einfachen Frage beantworten, ob eiin Zeichnen durchgeführt wird. Das ist eine konzeptionelle Frage.

    Allerdings hält der LayoutManager keine persistenten Daten. Deshalb kann es höchstens Controller, aber auf keinen fall Modell sein.

    Wenn du ihn nicht als View begreifen würdest, dann würde er bei einem Wechsel des "Äußeren" weiter existieren …

    Ich lösche *oho* sogar meinen storage, wenn ich das interface wechsel. Alles andere frisst unmengen an performance.

    Max

  • RE: Posen & Co.

    Du solltest vielleicht einfach nicht durch Zerstörung des Konzeptes Performance gewinnen.

    Nicht alles im Model wird übrigens persistiert, Modi etwa nicht. Das ist also ebenfalls kein taugliches Kriterium. Du hast schon ganz Recht: In der Wirklichkeit ist das etwas komplizierter. Deshalb würde ich die Unterscheidung auch nicht nach einzigartigen Kriterien vornehmen.

    +++
    Was ich jetzt nach nochmalliger Durchsicht gar nicht verstehe, ist, wie du auf den Gedanken komst, ich hätte behauptet, der Layout-Manager sei Model. Da habe ich nicht einmal etwas missverständllich geschrieben. Oder?
    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"?

  • RE: Posen & Co.

    Naja, ich hab mich damit jetzt seit 4 Jahren recht intensiv beschäftigt und hab auch schon den einen oder anderen Bug gefunden. Im Endeffekt halte ich meine vielleicht nicht für die ultimative alles-Lösung aber sie funktioniert fehlerfrei und extrem schnell.

  • RE: Posen & Co.

    Original von M.A.X
    Meine Klasse stammt direkt von NSObject ab. Und die Reihenfolge stimmt ja auch alles.
    Ja Deine eigene Klasse. Aber wenn ich das Problem richtig verstehe nicht die, für die sie sich ausgibt. In der Doku steht eindeutig, dass man eine Subklasse der überschriebenen Klasse erstellen muss. Und wenn man die nicht über eine Klassenhierarchie aus NSObject ableitet, dann muss man eben alle Instanzvariablen definieren.

    Stelle Dir vor, Du möchstest Dich irgendwo als Hr. Meier einschleichen. Dann machst Du Dir ein Namensschild auf dem Meier steht ([Du poseAsClass:[Meier class]]). Du musst aber damit rechnen, dass Dich jemand nach Dingen fragt, die nur Hr. Meier weiß, z.B. dem Namen seines Vaters. Deshalb musst Du Dich selbst darauf vorbereiten (d.h. Instanzvariablen von Hr. Meiers Vater nachdeklarieren).

    -- hns