Objc Runtime Datenstruktur "objc_class" - das "cache" Element

Das ist für mich total unlogisch. Wenn man die Analogie Algebra benutzt, dann besteht jede Algebra aus einer Menge und mindestens einer Operation, die auf der Menge definiert ist. Natürlich ist diese Operation für alle Elemente der Menge gleich. Dabei ist es unerheblich was die Elemente der Menge sind und wie die Operation definiert ist.

Daher ist es einfach logisch, daß Methoden einmal für alle Exemplare einer Klasse definiert sind, das gilt für normale Klassen und deren Exemplare genauso wie für Metaklassen und deren Exemplare, welche Klassen wären.

Es geht nicht um die Operation, sondern um die Speicherung. Es gibt keine Operation über Methoden. Leute, so kompliziert ist es doch nicht.

Wir haben eine Klasse K, die die Klassenmethoden A, B, C kennt. Haben wir eine Klasse K', so hat diese potentiell andere Methoden D, E, F. Also werden die Klassenmethoden zur Klasse gespeichert. Für K { A, B, C }, für K' { D, E, F }.

Dann haben wir Instanzen I, I', I'' von K. Jetzt wäre es logisch, dass jede Instanz ihre Instanzmethoden speichert. Alle Instanzen von K, also I, I', I'' haben jedoch den gleichen Methodensatz. Also wäre es einfach Speicherverschwendung, wenn man das zu jeder Klasse speichern würde. Was macht man? Richtig, wenn alle Instanzen von K denselben Methodensatz haben, dann speichert man ihn einmal bei der Klasse. Damit hat die Klasse K auch einen Instanzmethodensatz { a, b, c }. Diese Struktur ist jetzt unter Speichergesichtspunkten optimiert, weil man nicht mehr zu jeder Instanz die Liste führen muss.

Demnach könnte man eine Struktur bei K machen, welche sämtliche Methoden speichert. Dann ergeben sich aber zwei Probleme:

a) Ich habe die Methoden jetzt A, B, C bzw. a, b, c genannt. Sie können aber zur Laufzeit gleich heißen. Wie unterscheidet man dann noch Klassen- und Instanzmethoden? Gut, irgendwie bekäme man das noch hin.

b) Den Instanzmethodensatz benötigt man erst nach der ersten Instantierung. Den Klassenmethodensatz benötigt man vorher.

Beides lässt sich jetzt leicht dadurch lösen, dass man eine weitere Struktur einführt, welche die Klassenmethoden speichert. Diese Erzeugt man vorher. (Ich kann mir vorstellen, dass sie wegen +alloc sogar bereits bei Programmstart erzeugt werden muss. Müsste man nachprüfen.) Damit erzeugt man die Liste der Klassenmethoden.

Irgendwann viel später und nur wenn es notwendig ist, aka wenn das Klassenobjekt das erste Mal +alloc empfängt und +initialize ausführt, dann und erst dann wird die Instanzmethodenliste erzeugt.

Denn die Instanzmethodenliste benötige ich erst dann, wenn ich die Klassenmethodenliste bereits benötigte. Ich kann niemals die Auasfürhrung einer INstanzmethode vor der Ausführung einer Klassenmethode haben. Also habe ich sicher bereits die Klassenmethodenliste, bevor ich die Instanzmethodenliste habe. Ich könnnte das jetzt freilich kopieren. Aber wozu? Ich erzeuge Die Klassenmethodenliste in einer Struktur, die ich Metaclass nenne und sobald ich eine Instanz habe, erzeuge ich die Instanzmethodenliste in einer Struktur die ich Class nenne und diese lasse ich auf die Metaclassstruktur verweisen.

Wo liegt jetzt da das Problem? Besser scheint es mir nicht zu gehen.

Was das mit Gruppentheorie zu tun hat oder warum jemand anderes das lieber suboptimal haben will, verstehe ich nicht.

Original von Tom9811
Es geht nicht um die Operation, sondern um die Speicherung. Es gibt keine Operation über Methoden.

In der von mir gebrauchten Analogie Klasse = Algebra, Methode = Operation, Exemplare = Element der Menge.

Was die Speicherung betrifft:
Es kann zwischen Metamethoden und Methoden nicht unterschieden werden, da Objective-C für alle ein und dieselben Selektoren kennt, und diese schon zum Compilezeit aufgelöst werden. Die Zuordnung von Methodename zum passenden Selektor ist also eindeutig statisch und erfolgt zum Compilezeitpunkt. Die einzige Ausnahme ist das RPC-Feature von Objective-C, da muß dann das ganze trotzdem zur Laufzeit erfolgen. Aber das kann jetzt mal vernachlässigen.

Wir haben eine Klasse K, die die Klassenmethoden A, B, C kennt. Haben wir eine Klasse K', so hat diese potentiell andere Methoden D, E, F. Also werden die Klassenmethoden zur Klasse gespeichert. Für K { A, B, C }, für K' { D, E, F }.

Dann haben wir Instanzen I, I', I'' von K. Jetzt wäre es logisch, dass jede Instanz ihre Instanzmethoden speichert.

Das ist total unlogisch. Warum sollte das so sein? Die Methoden sind doch für alle Exemplare gleich. Eine Klasse ist eine Datenstruktur, sie erlaubt für eine Menge von Exemplaren Operationen (hier Methoden genannt) zu definieren. Diese Operationen sind nur auf der Menge definiert und nicht auf ihren Elementen (hier die Exemplare einer Klasse).

Alle Instanzen von K, also I, I', I'' haben jedoch den gleichen Methodensatz. Also wäre es einfach Speicherverschwendung, wenn man das zu jeder Klasse speichern würde.

Nein, der Speicherverbrauch ist nur ein Nebeneffekt, der hier aber nicht am wichtigsten ist. Es widerspricht der grundlegenden Logik von OOP.

a) Ich habe die Methoden jetzt A, B, C bzw. a, b, c genannt. Sie können aber zur Laufzeit gleich heißen. Wie unterscheidet man dann noch Klassen- und Instanzmethoden? Gut, irgendwie bekäme man das noch hin.

Aus Effizienzgründen macht das schon der Compiler, siehe Apple Doku. Genaueres interessiert nicht Stichwort Compilermagie.

b) Den Instanzmethodensatz benötigt man erst nach der ersten Instantierung. Den Klassenmethodensatz benötigt man vorher.

Nein, die Methoden sind vorher schon da und müssen auch vorher schon eingebunden werden. Zum Beispiel kannst Du ja schon vor dem Anlegen eines Exemplar einer Klasse nachfragen welche Methoden sie für Exemplare kennt. Überhaupt liegen die Methoden eh im Speicher rum, es ist vollkommen sinnlos sie nicht gleich einzubinden.

Diese Erzeugt man vorher. (Ich kann mir vorstellen, dass sie wegen +alloc sogar bereits bei Programmstart erzeugt werden muss. Müsste man nachprüfen.)

Nein, das kann nicht sein. Da sowohl Methoden wie Klassenmethoden dieselben Selektoren nutzen werden sie auch in ein und derselben Struktur verwaltet. Es gibt keinerlei Grund nicht gleich alles beim Laden der Applikation zu initialisieren. Die ganze Initialisierung ist kein triviales Problem bei einem C-Compiler, wann welche Datenstrukturen initialisiert werden siehe ISO C Norm bzw. das Runtime-Linker Handbuch für die jeweilige Plattform. Aber die Struktur muß so dynamisch sein, daß man während der Laufzeit der Applikation weitere Elemente hinzufügen kann, da man Objektmodule nachladen kann und diese neue Klassen einführen können.

Gut, prototypenbasierte Sprachen, die zu jeder Instanz die Methodenliste speichern /müssen/, sind ebenso unlogisch wie die Zuordnung von Instanzmethoden zu Instanzen. OOP sind sie auch nicht, irrtümlich hält sie alle Welt dafür.

Gut, es kann auch nicht sein, dass der Eintrag für die Klassenmethode alloc vor der Instantierung vorhanden sein muss, weil nämlich die erste Instanz nicht durch alloc erzeugt wird, sondern von der RTE herbeigebetet wird. Möglicherweise wird aber auch nur das Dispatching für +alloc aus der Kristallkugel gezaubert. Das ist auch logischer und eher OOP.

Danke für die Diskussion!

Original von Tom9811
Gut, prototypenbasierte Sprachen, die zu jeder Instanz die Methodenliste speichern /müssen/, sind ebenso unlogisch wie die Zuordnung von Instanzmethoden zu Instanzen.

Ich weiß jetzt nicht, wie Du zu dieser Aussage kommst. Sie ist schlichtweg unsinnig! Auch C++ legt die vtables nur einmal ab und nicht zu jedem Exemplar! Quelle unter anderem "The Design and Evolution of C++; Stroustrup". Bei Objective-C ist die Struktur dynamisch bei C++ statisch, das ist der ganze Unterschied. Du solltest Dich dringend mal mit diesem Thema grundlegend auseindersetzen und Deine eklatanten Defizite aufarbeiten.

Nein, sie ist nicht unsinnig, sondern zutreffend.

a) C++ ist keine prototypen-basierte Sprache. Ich verstehe daher deinen Vergleich schon vom Ansatz her nicht.

Zu Prototypen und prototypen-basierten Sprachen:
de.wikipedia.org/wiki/Prototyp_%28Entwurfsmuster%29
de.wikipedia.org/wiki/Self_%28Programmiersprache%29

b) Du verwechselst Konzept mit Implementierung. Konzeptionell ist eine Instanzmethode eine Instanzmethode und arbeitet daher auf der /einen/ Instanz. Dieses Konzept nennt man OOP.

Dass man das in der /Implementierung/ optimieren kann, bei C++ und bei Objective-C, ist keine Frage des Konzeptes.

In dieser Frage sind sich übriogens C++ und Objective-C einig.

Zu a)
Fehler von mir, an Sprachen, die Klassen über Prototypen definieren dacht ich nicht
Aber auch die Definition von Klassen über Prototypen ergibt zwangsläufig, daß man die Methoden nur einmal pro Klasse vorhält. Wenn man die Methoden redefiniert, dann erzeugt man automatisch den Prototypen für eine neue Klasse.
Zu b)
In diesem Punkt irrst Du Dich gewaltig. Der klassische OO-Ansatz definiert Methoden für alle Exemplare einer Klasse.

Zitat aus "Objektorientierte Analys und Design, Booch"
Eine Klasse ist eine Menge von Objekten, die eine gemeinsame Struktur und ein gemeinsames Verhalten aufweisen.

Zitat aus "Smalltalk-80 The Language, Goldberg, Robson"
A class describes the implementation of a set of objects that all represent the same kind of system component. The individual objects described by a class are called instances. A class describes the form of its instances' private memories and it describes how they carry out their operations.

Die Definition der Methoden ist bei den klassischen OO-Sprachen eine Eigenschaft der Klasse und nicht deren Exemplaren. Das ist ein fundamentaler Aspekt und hat überhaupt nichts mit Implementationsaspekten zu tun. Es ist daher nur logisch, die Methoden auch nur einmal pro Klasse zu definieren. Alles andere würde dem grundlegendem OO-Gedanke zuwider laufen. Die etablierte Sprechweise "man schicke eine Nachricht an ein Objekt" vernebelt etwas die Realität. Insbesondere bei OO-Sprachen mit mehrfacher Polymorphie ergibt das keinerlei Sinn mehr. An welches der Objekte verschickt man denn nun die Nachricht? Die 1:N Beziehung wird in der Sprechweise genau verkehrt herum benutzt. Es ist so, daß der Dispatcher abhängig von den Typen der Objekte die Nachricht dispatch und der richtigen Methode alle Objekte als Parametern übergibt.

Zu a)
Nein, dort werden keine Methoden in Klassen vorgehalten. Genau genommen hat man gar keine Klassen mehr. Dafür gibt es ja Prototypen. Und da sich jede Kopie eines Prototypen unterschiedlich entwickeln kann, iinsbesondere Methoden hinzugefügt werden können, kann man die Methoden auch nur zu jeder Instanz halten. Die RTE weiß nichts von Klassen und Instanzen. Fü sie ist das Einerlei: Alles irgendwie Objekte.

Das ist ja der Gedanke von Prototypen!

Es ist ürbiegns auch nicht rchtig, dass die Klasse mir die Frage beantwortet, welche Instanzmethoden ausgeführt werden. Das macht die Instanzmethode -respondsToSelector:. Damit ist diese Eigenschaft (existiert Instanzmethode?) eine der Instanz.

Dass C++ das nicht sauber trennt, findet seine Ursache einfach darin, dass es ursprüngich "c with classes" hießt, nicht "c with objects". Dsa hat aber mit moderner OOP nichts zu tun.

Zu b)
Daher ist es ganz gewiss kein fundamentaler Aspekt, dass Methoden in Klassen gehören. Methoden gehören in Objekte. Das ist der Aspekt.

Ob die Sprache Instanzen nach Klassen gegliedert oder nicht, spielt dafür gar keine Rolle. Dies is teine Frage der Typisierung, nicht der OO. Jeder typlosen Sprache ihre oo Eigenschaft abzuerkennen ist gelinde gesagt absurd. Prototypen-basierte Sprachen wären dann etwa nicht oo. Mit dieser Ansicht dürftest du ganz allene stehen. Die übliche Ansicht ist, dass sie sogar die Vollendung der OOP sind.

- Logisch schicke ich eine Nachricht an eine Instanz, nicht an eine Klasse. Man verschickt sie an this oder self. Man verschickt sie nicht an die Klasse. (Das macht man freilich bei Klassenmethoden.) undsind logisch ganz gewiss nicht dasselbe.
- Logisch kommt die Methode nur an die Instanzvariabeln.

Das ist der Gedanke von OOP: Die /Verbindung/ von Code und Daten zu einem Objekt.

Und wenn man block-orientierte Sprachen hat. Smalltalk ist sehr wohl in der Lage, nämlich über Blöcke, eine Methode einer bestimmten /Instanz/ zuzuweisen. Den Vergleich hatte ich vorhin ausgelassen, weil er etwas unfair ist. E geht mehr auf die Block-Struktur von Smalltalk als auf die Klassenstruktur ein.

Deine persönliche Auffassung ist ziemlich sonderbar und so garantiert nicht mehrheitsfähig. Es gibt mittlerweile standardisierte Muster, die man in der Softwareentwicklung nutzt. Bahnbrechend dafür war unter anderem das Buch "Booch, Grady: Objektorientierte Analyse und Design. Addison-Wesley" oder die Bücher von Peter Coad zum Thema OOA, OOD und OOP. Auch in Smalltalk80, The Language wird keine andere Auffassung vermittelt. Ich habe noch ein paar weitere Bücher zum Thema, in keinem dieser Bücher vertritt jemand Deinen Standpunkt.

Basierend auf diesem von Booch, Coad und anderen beschriebenen Verfahren wurde UML entwickelt. In der OOA Phase werden reale Objekte (Objekte aus der realen Welt und keine Objekte im Speicher eines Computers) abstrahiert und zu Klassen modelliert. Objekte sind in der OOA immer Exemplare von Klassen. Im statischen Modell werden Objekte gar nicht benötigt und es werden nur Klassen und deren Abhängigkeit voneinander beschrieben, im dynamischen Modell wird der Lebenszyklus von Objekten (Exemplaren von Klassen) beschrieben. Auch in der anderen Literatur, die ich zum Thema habe bzw. kenne, wird die Auffassung vertreten, die Booch et al. letztlich zu UML ausgearbeitet haben.

Worauf beziehst Du Dich in Deiner doch stark abweichenden Auffassung von OOP?
Gibt's dafür irgend eine Referenz?
Gibt es Literatur oder Links die Deinen Standpunkt unterstützen würde?
Oder ist das ganze nur Deine persönliche Interpretation von OO?

Was das Theme Prototypen betrifft. Es gibt Programmiersprachen, die definieren Klassen explizit (Smalltalk, C++, ...) und Sprachen die definieren Klassen implizit via Prototypen. Auch wenn man den Begriff Klasse nicht explizit verwendet, so kommt er doch im Design vor.

Ich kann außer allgemeinen und zusammenhanglosen Aussagen in deinem Beitrag keinen konkreten Bezug zu meinem Beitrag finden.

Ich denke, dass die Fortführung der Diskussion keinen Sinn hat.

Nur mal so zum Nachlesen:
"Self ist wie JavaScript eine prototypenbasierte Programmiersprache ohne Klassendefinitionen. Die Mehrzahl aller objektorientierten Sprachen basiert hingegen auf Klassen.
Ein Self-Objekt ist nicht die Manifestation einer Klasse im Sinne eines Bauplans, sondern direktes Resultat eines Prototyps. So wird einem Self-Objekt auch nicht der Lebensatem eingehaucht, indem man es auf Basis einer Klassenschablone instanziiert, sondern indem man ein bestehendes Objekt kopiert und dieses entsprechend abändert."

Aber irgendwie kommt da ja das Wort "Klasse" vor -- Um die Abwesenheit zu beschrieben.

Aber mutmaßlich ist Self gar nicht oo …

Da ich mich auf die grundlegende Interpretation vom Konzept Klasse und Methode im Softwaredesign bezog, hat das sehr wohl etwas mit Deinem Beitrag zu tun.

Zum Thema self.
1) Woher stammt das Zitat? Quellenangabe ist eigentlich eine Selbstverständlichkeit.

2) Das steht, self kennt keine Klassendefinition. Das ist kein Widerspruch zum dem, was ich geschrieben habe. Eine Klassedefinition ist eine explizite Definition einer Klasse. Prototypen definieren Klassen implizit, daher braucht es keine speziellen Sprachkonstrukte für das Konzept Klasse. Es ändert aber nichts daran, daß man das Konzept Klasse im Design von Software nutzt.

Ich habe nicht bestritten, dass das Konzept Klasse in der Softwaretechnologie benutzt wird.

Das Konzept Klasse ist indessen nicht für den Begriff OOP notwendig. Man kann OOP mit Klassen haben, man kann OOP ohne Klassen haben. Du solltest da eklatante Defizite aufarbeiten.

Für den Begriff OOP ist notwendig, dass Code und Daten gekapselt werden. Ob das in einer Instanz erfolgt oder in einer Klasse, ist für OOP völlig gleichgültig.

Und es ist einfach so, dass respondsToSelector: eine Instanzmehtode ist. Ich kann das ja nun nicht ändern. Da das offenkundig nicht deiner Defintiion von OOP entspricht, ändert daran nichts.

Das obige Zitat stammt aus der Wikipdia zu Self.

Ich sehe wirklich keinen Sinn mehr in der Diskussion, da du offenkundig nur klassenbasierte Modelle kennst und nicht bereit bist, dieses zu erweitern.

Das Konzept "Klasse" ist ein fundamentales Konzept der OOA, OOD und OOP. Wenn dem nicht so ist, hätte ich gerne einen Quellenangabe wo noch jemand außer Dir diese Meinung vertritt.

Was zeichnet alle Exemplare einer bestimmten Klasse A aus?
Sie haben alle dieselben Attribute und verstehen alle dieselben Nachrichten, und das ist das Mantra, um das sich alles bei der OOP dreht. Nenne mir nur eine Quelle, die nun belegt, daß es logisch sei, die Methoden pro Exemplar zu implementieren. Und bitte fang nicht wieder an, Prototypen dafür zu benutzen. Wenn ein Objekt neue Methoden hat, definiert es implizit eine neue Klasse B die von A erbt. Was kein Widerspruch zu obiger Aussage darstellt.

In Self gibt es keine Klasse (oder wie du es auch immer nenen möchtest), die alle dieselben Attribute kennzeichnet und diselben Methoden. Es gibt sie einfach nicht, mein Gott. Der Prototyp erfüllt diese Funktion gerade nicht.

+++

Ich hatte dir bereits einen Beleg ziterit. Dort finden sich auch am Ende des Artikels zahlreiche Verweise.

So, jetzt ist aber wirklich gut.

Original von Tom9811
In Self gibt es keine Klasse (oder wie du es auch immer nenen möchtest), die alle dieselben Attribute kennzeichnet und diselben Methoden. Es gibt sie einfach nicht, mein Gott. Der Prototyp erfüllt diese Funktion gerade nicht.

Wirklich? Du hättest den Text weiterlesen sollen.
Wikipedia Artikel zum Thema self
Analog zum aktuellen Beispiel, würde das Objekt BankKonto als logische Konsequenz weder eine „einzahlen“- noch eine „auszahlen“-Methode besitzen. Vielmehr hat das BankKonto-Objekt nun ein Eltern-Objekt, welches die genannten Methoden enthält. Auf diese Weise ist es möglich, unzählige Kopien des Bankkonto Objekts zu erzeugen, deren Verhalten durch eine einzige Änderung am Eltern-Objekt verändert werden können.
Das hört sich doch stark danach an, daß man Exemplare einer Klasse hat, deren Klasse man während der Laufzeit verändern kann.

Keine Ahnung, ob sich das für dich so anhört. Für mich nicht, was daran liegen mag, dass ich schon mit Self programmiert habe.

Der Prototyp in dem Beispiel muss eben gerade nicht die Methoden des delegierenden Objektes vollständig implementieren. Umgekehrt muss auch wiederum der Delegierer sämtliche Methoden des Protoypen anbieten. Sie können völlig attribut- und methodenfremd sein.

Das Konzept geht übrigens auch in Objective-C (und sogar in C++!)die Instanz (übrigens: Instanz!) delegate als Klasse von delegating (ich dachte ja nun, dies sei MyClassB) zu bezeichnen, ist besonders … Überhaupt: Da man sich beliebig viele solcher Delegates anlegen kann und das nach deiner Ansicht sogar Klassen sind, kennt also Obejctive-C doch Mehrfachvererbung!!!!!!!!!!!!!!!!!! Was man hier nicht alles lernt …

Und natürlich wird dieses Konzept auch von Objective-C inkorporiert. Man nennt es dort Forwarding (Der Begriff Delegate bezeichnet eigentlich etwas anderes in Objective-C, genauer: Cocoa). Die Begriffsschärfe ist in dem Bereich leider insgesamt sehr gering. Erstaunlich ist, dass bei der Beschribung von forwardInvocation: wiederum Apple selbst von einem Delegate spricht.

Aber ich freue mich selbstverständlich, dass du dich dort informierst.

So jetzt, ist aber wirklich, wirklich gut. Du kannst ja zum Treffenkommen. Da ist eine Diskussion bequemer und einfacher.

Danke für die Einladung, aber dieses mal wird's wohl nichts.

Delegation kann man unter anderem dazu nutzen Mehrfachvererbung nachzubilden, wenn die betreffende Sprache das nicht kann oder man während der Laufzeit die "Vererbungshiersachie" verändern können muß. Statt "A is a B" wird daraus ein "A contains a B". A, B sind Klassen. Aber das ordne ich unter Trivialität ein.

Original von Tom9811
übrigens: Instanz!)

"Instanz" ist ein Anglizismus. Meist wird in Deutschen Lehrbüchern einfach "Objekt" genutzt, wobei "Exemplar" der eigentlich korrekte Begriff ist. "Objekt" ist etwas zu unspezifiziert. "Instanz" wird trotzdem vielfach benutzt. In den Fachbüchern, die ich habe, wird dagegen "Instanz" nicht benutzt. Wobei ich das als nicht repräsentativ einstufen würde, dazu sind die deutschsprachigen Fachbücher einfach zu wenige. Die englischen verwenden natürlich "instance".

Als Anwalt mag Deine Affinität zu Instanz möglicherweise anderweitig begründet sein.

Batürlich kann man mit Delegates Mehrfachvererbung nachbilden. Das sagte ich ja. Aber es bleibt beim Nachbilden. Und der Delegierer ist gewiss keine Instanz der Klasse Delegate. Deshalb hat dein obiger Textauszug nichts mit Klassen zu tun.

Neee, Instanz ist kein Anglizismus, sondern ein Latinizismus (wenn man das so nennt). Man kann es auch in C++ durch Objekt ersetzen, nicht bei allen Sprachen.

Bei Objective-C gibt es zwei Arten von Objekten. Instanzobjekte und Klassenobjekte. Die Bezeichnung Objekt -- wenn auch noch teilweise üblich -- ist daher unscharf. Die generelle Gleichsetzung der Begriffe ist fehlrerhaft. Meine Affinität resultiert daher übrigens einfach aus sprachlicher Schärfe.

Bei prototypen-basierten Sprachen ist die Unterscheidung wiederum obsolet, da es keine Klassen gibt, mithin keine Klassenobjekte. Daher ist es unschädlich, Instanz oder Objekt zu sagen. Keine Typisierung, kein Typ, keine Unterscheidungsnotwendigkeit.

Original von Tom9811
Batürlich kann man mit Delegates Mehrfachvererbung nachbilden. Das sagte ich ja. Aber es bleibt beim Nachbilden.

Wunderbar da herrscht in diesem Punkt ja Einigkeit.

Neee, Instanz ist kein Anglizismus, sondern ein Latinizismus (wenn man das so nennt). Man kann es auch in C++ durch Objekt ersetzen, nicht bei allen Sprachen.

Die Verwendung als Synonym für Exemplar ist ein Anglizismus, und gilt als fehlerhafte Übersetzung beziehungsweise schlechtes Deutsch. Das findet sich eigentlich in jedem gutem Lehrbuch. Daß der Begriff Instanz letztlich auf das Lateinische zurückgeht, hat in diesem Kontext eine untergeordnete Bedeutung.

Bei Objective-C gibt es zwei Arten von Objekten. Instanzobjekte und Klassenobjekte.

In guter englischsprachiger Literatur werden die Begriffe "instance of class" oder "instance of metaclass" verwendet.

Die generelle Gleichsetzung der Begriffe ist fehlrerhaft.

Das macht ja auch niemand. Objekt ist der Oberbegriff und bedarf ggf. einer klärenden zusätzlichen Bestimmung.

Meine Affinität resultiert daher übrigens einfach aus sprachlicher Schärfe.

Exemplar ist der korrekte Deutsche Begriff, er drückt exakt dasselbe aus. Daher erklärt sprachliche Präzision nicht Deine Affinität zu "Instanz". Mir ist es egal, was für einen Begriff Du verwendest, nur fang nicht an mir das Verwenden von "Exemplar" vorzuhalten.