Jo, das hat bei mir auch etwas gedauert, bis ich den OP verstanden habe, weil es ja "eigentlich" ganz anders ist, nämlich so, dass man beim Posing keine neuen Members haben darf.

Und bei genauer Betrachtung ist es in der Tat so, dass er die Membervariablen nicht in der posierenden Klasse anlegt, sondern in der Basisklasse. Er will sich einfach die unbekannte Basisklasse nachbilden. Mit Posing hat das nichts zu tun.

Wir verstehen schon alle sehr gut, was du meinst. Du verstehst bloß nicht, dass du an der falschen Stelle suchst.

Das frage ich mich allerdings auch …

Und in vier Jahren bist du zum Schluss gekommen, der Layout-Manager sei ein View, weil er zeichnet?

Jepp, das gilt vor allem, wenn du das Problem hast. Dir ist jetzt aber schon aufgefallen, dass *alle* das Problem in deinem Missverständnis sehen?

ALLES SCHLAMPEN AU?ER MUTTI!!!!!!!!!

a) Nein, ein Header ist etwas anderes als eine Bekanntmachung. Das versuchen wir dir jetzt aber schon seit zwei Tagen zu erklären und scheitern damit offenbar.

b) Kopieren ist nachbilden.

c) Du musst die Members angeben, weil du *nachbildest*, wobei es völlig gleichgülltig ist, ob du das kopieren, nachbilden oder rosa Unterhose nennst.

d) Du musst die Members nicht angeben, weil du posierst.

Es ist aber auch müßig. Du hattest 3 Wochen Crashs am Hut, nicht ich.

Original von M.A.X
Ok, dann erkläre mir mein Misverständnis. Ich erkläre dir deins:

Ich habe nichts weiter gemacht, als mir den Header mittels Class-Dump aus dem AppKit zu holen. Die Klasse aus dem App-Kit stammt von NSObject ab. Dann habe ich diesen Header in mein Programm kopiert und abgeleitet. Die abgeleitete Klasse habe ich implementiert und dann per poseAsClass: über die andere posiert. Du bist immernoch der meinung, dass ich etwas nachgebildet hätte. Aber das habe ich nicht. Ich habe ausschließlich meinem Programm diese Klasse bekannt gemacht. Ein Header ist nichts anderes als ein bekanntmachung. Ich habe rein gar nichts implementiert.

Genau das ist ja der Fehler...

Man darf anscheinend nur eine Subklasse der Originalklasse posen und nicht eine andere, die zufällig ebenfalls von NSObject abgeleitet ist.

=> probiere es mal zweistufig:

@interface MeineNachbildungDerKlasse : NSObjekt
{
... Variablen laut ClassDump
}
@end

@interface MeineKlasseDieIchAlsMeineSuperKlassePosenWerde : MeineNachbildungDerKlasse
@end

Einen Unterschied macht das z.B. bei [super dealloc]...

-- hns

Ok. Hatte ich schon nicht mehr in Erinnerung - sorry.

Die Frage war ja eigentlich:

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?

Eigentlich ist das egal - denn Du musst die Variablen ja irgendwie bekannt machen.

Wenn es der Compiler macht: dann musst Du ihm die Variablen angeben.
Wenn es zur Laufzeit geschieht, dann muss das Laufzeitsystem die Variablen kennen um die Größen zusammenzuzählen. Und die Annahme, dass sich die Größtenberechnung auf die Originalklasse und nicht die selbst definierte, geposte Klasse bezieht trifft offenbar nicht zu.

Vielleicht folgende Überlegung: poseAs: überschreibt auch -alloc. Und der nimmt die Größe von Instanzen der *aktuellen* Klasse.

-- hns

Das hat er ja gemacht.

Nochmal:

Du hast eine x-beliebige Klasse K. Von der kannst du eine Subklasse K' machen und _nur diese_ (keine weiteren Subklassen von K') dürfen als K posen. Dabei dürfen *keine* Members hinzugefügt werden. K' muss exakt die gleichen Members haben wie K. Wenn du also ableitest, *muss* das Interface von K' *leer* bleiben (bezüglich der Instanzvariablen).

Er hat eine Klasse K aus dem System genommen, ohne den Header zu haben. Diese hat Member. Seine Posing-Klasse muss also *eben genau diese Member haben*. Wenn er jetzt aber K (als Prothese für System-K) leer lässt und K' leer lässt, dann hat K' *keine* Member. Wenn jetzt K' für System-K posiert, sind die Anzahl der Member *unterschiedlich*.

Das muss krachen.

Das Problem liegt nicht im Posieren, sondern darin, dass er die Klasse unvollständig nachbildet.

Davon unabhängig gibt es zwei Klassen mit gleichen Namen im Laufzeitsystem. Du weißtja nicht, wer wie wann wo die Klassenobjekte erzeugt. In Cocoa gibt es jedenfalls irgendwo diese Klasse. In seiner Source gibt es diese Klasse. Da kann man ja vllt noch den Linker austricksen.

Da aber bei Objective-C Klassen immer ein Klassenobjekt haben, existieren auch die Klassenobjekte zweimal. Ich glaube nicht, dass die RTE darauf Rücksicht nimmt, dass ein Singleton nun zweimal existiert.

Oder eben nur einmal. Aber welche Version dann? Das ist die Kombi von einer undokumentierten Klasse mit einem undokumentierten Verhalten.

s/definieren/deklarieren

Es mag auch sein, dass es da nur einmal gibt (letzter Absatz). Das spielt keine Rolle. Du hast einmal das Dingens bei dir in der Source. Einmal irgendwo in Cocoa. Du hast keinerlei Verbindung dazwischen. Du *hoffst*, dass das irgendwie gut geht.

Du hast auch immer eine Implementierung, wenn du mindestens von NSObject ableitest. Sogar wenn du @implementation leer lässt, gibt es ja was.

Wenn du aber ohnehin andere Interfaces hast, kann das erst recht nicht gut gehen.

Wenn Die Klasse nicht zur Laufzeit gebaut wird, ja.

Ansonsten: Nein!

+++
Grundsätzlicher:
Klassen sind alleine für den Compiler interessant. Sprachen wie C++, die keine Klassenobjekte kennen, müssen zur Laufzeit nichts von der Klasse wissen, wenn man es nicht zum debuggen braucht. Dier erzeugen maximal noch ne vtable und das war es.

In Objective-C ist das aber ambivalent. Der Klasse als Source-Code Dingens steht spiegelbildlich ein Klassenobjekt zur Laufzeit gegenüber. Wenn du die Klasse aus der Source hat, wird der Compiler an etwa 1273631287 Stellen Code erzeugen, der davon ausgeht, dass das Laufzeit-Panton übereinstimmt.

Wird das Klassenobjekt indessen dynamisch erzeugt, so kannst du so ziemlich ganz in die Röhre schauen.

Um das herauszufinden, müsste man in die RTE schauen und zudem am besten ein bisschen in den Cocoa-Sourcen. Beides habe ich jedenfalls nicht. (Gibt es das Dingens eigentlich in GnuStep?)

+++
NSUndoText* hat jedenfalls nichts gefunden.

Den ersten Teil hatte ich vor Ewigkeiten (in Forenmaßstäben ohne Berücksichtigung von Josef) gesagt. Der Rest bezog sich nicht auf deine ursprüngliche Frage, sondern war ein *zusätzlicher* Hinweis auf die Gefahren, die du selbst bei ordnungsgemäßter Kopie hast. Der Anlass war das "Jetzt funktioniert es ja" oder so ähnlich.

Sie darf auch nicht kleiner sein, weil etwa der Compiler verschiedene Angaben für das Laufzeitsystem vorbereitet, etwa die Offsets für die Instanzvariablen. Hast du weniger, so fehlen die. Wir können beide nicht sagen, was dann passiert. Ebenso kann es bei der Allozierung Probleme geben.

In solchen Fällen crasht es fast nie definiert.

a) Auf den korrupten Teil muss nicht sofort zugegriffen werden.
b) Es wird kaum so sein, dass die RTE exakt für jede Instanz Speicher vom System anfordert. Vielmehr wird das in Blöcken gemacht. Daher können etwa auch Elemente eines C-Arrays "gehören", wenn du über das Ende hinausläufst.
c) Möglicherweise -warhscheinlich beim endlichen Crash- befiondet sich da etwas anderes. Das zerstörst du. Eine Zeitlang kann das gut gehen. Irgendwann wird das wichtig.
d) Stelle dir nur vor, dass nach jeder internen Speicheranforderung in Manier einer verketteten Liste der nächhste _interne_ Block adressiert wird. Bei einem alloc schaut er etwa nach, wo der nächste interne freie Speicher in dem vom System gelieferten Block liegt. Hast du da etwas zerbritzelt, fällt das dann auf. Muss aber auch nicht. Hast du es so zerbritzelt, dass es etwas auf den ersten Blick gültiges herauskommt, fängt er vllt nur an, jetzt etwqasa anderes zu zerbritzeln. Das möglicherweise ...
e) Jeder Zeiger, gleich für was, führt zu einem Fernzerbritzeln. Das kann Ewigkeiten dauern, bis dann etwass crasht. Zu debuggen ist das fast gar nicht.

MAW: Wenn du nicht sicher weißt, was da läuft, kannst du gar nicht sagen, was passiert.