Es kommt nicht auf meine Präferenzen an, sondern auf die der Sprache.

Aber ein Recompile wäre sicherlich nicht ausreichend. Sobald ich die *Möglichkeit* der Ableitung bieten möchte, *muss* ich sie als virtual angeben. Dann bin ich aber aus dem Inlining raus (siehe oben).

Es gibt auch lokale private Properties und private Methoden, an deren Virtualisierung absolut kein Bedarf besteht. Selbst über Posing kommt man m. E. nicht an lokal Privates heran, da es ja verdeckt wird, und ich finde das gut so.

Leider gibt es m. E. für diese wirklich internen Methoden kein Objective-C Sprachmittel zu einem früh bindenden Aufruf, bei welchem ich ebenfalls kein Problem bei einem denkbaren Inlining zu erkennen vermag.

Gelegentlich mag es sinnvoll sein, auch lokal private Properties über Zugriffsfunktionen abzuschirmen, aber ein Objective-C Sprachmittel, das dieses tatsächlich sicherstellt, habe ich leider noch nicht entdeckt. Es wäre wünschenswert. Vielleicht hilft mir da jemand auf die Sprünge.

OMG was für Code produzierst du und wie sieht der nur aus? NEIN, ich will ihn nicht sehen! *schauder*

Ich glaube, du vermischst jetzt Themen!?

a) Die Abschirmung lokaler Properties über Zugriffsmethoden, also ein Verbot, diese unmittelbar über Zuweisung anzusprechen, kenne ich weder in C++ noch in Objective-C, was dieselbe Klasse angeht. Für Subklassen und fremde Klassen kenne ich es in C++ wie in Objective-C (private vs. proteted). Ich sehe hier also weder Unterschied zwischen den Sprachen noch einen Zusammenhang zum Inlining.

b) Ein Verbot der Ableitung gibt es in Ojective-C nicht, wohl aber in C++. Dies entspricht der Philosophie und ist beabsichtigt. Grundsätzlich kann jede Methode abgeleitet werden, ist also virtual.

c) Inlining von Methoden ist nur dann sinnvoll anwendbar, wenn man diese nicht ableiten kann. Sobald das Wort virtual mit dem Wort inline paarweise auftritt, weiß der Compiler nicht mehr sicher (bis auf ein paar Ausnahmen, was ich jetzt nicht jedes Mal wiederholen werde), ob er die Methode inlinen darf. Er lässt es daher bleiben. Faustregel: "Virtual ist stärker als Inlining."

d) tjp kombinierte meine Aussage 1 "Du sollst auch für private Eigenschaften Accessoren haben" mit der Aussage 2 "Inlining von Methoden (also auch privaten Accessormethoden) ist nicht sinnvoll." Dabei überging er die von mir durchaus nicht verschwiegenen Gründe für Aussage 1. Diese Gründe führen aber eben gerade dazu, dass ich auch ableiten können möchte. Dies bedeutet, dass wir wieder bei c) sind, Inlining also keinen Sinn ergibt.

Wenn man es ganz genau nimmt, ist in Objective-C ohnehin aus ganz anderen Gründen Inlining von Accessoren völlig am Sprachkonzept vorbei: Objective-C lässt es ja zu, dass erst zur Laufzeit aus einem Klartext der Accessor-Name gebaut wird. Dies ermöglicht erst Key-Value-Coding, Key-Value-Observing, Core Data, Cocoa Bindings. Wenn nun der Accessor reiner Inline-Code wäre …

Umgekehrt kann meines Erachtens der Compiler nie erkennen, ob eine bestimmte Instanz einer bestimmten Klasse angehört, weil es durchaus erlaubt ist, spezialisierte Subklassen zu "konstruieren". Also sogar bei einem Code wiekann der Compiler nicht ausschließen, dass ich es in Wahrheit mit einer Subklasse von Entity zu tun habe.

Das ist keinesfalls vorsätzliche Quälerei von Compilerbauern, sondern hat einen Grund: Man kann auf diese Weise spezialisierte Subklassen verwenden, Objekte wiederbenutzen (-numberWithInt:1 wird nur einmal instantiert, nur einmal, nur einmal, also nicht dreimal), auch CoW implementieren. Was ist also der Grund: Richtig, Performance-Steigerung.

Das mag im Ansatz komplexer sein, als einfach einen Call auszulassen … Ich glaube nicht, dass es weniger performant ist. Einfach nur schlauer.

Original von Tom9811
c) Inlining von Methoden ist nur dann sinnvoll anwendbar, wenn man diese nicht ableiten kann.

Nein, Inlining ist auch bei virtuellen Methoden sinnvoll, wenn diese auch statisch aufgerufen werden können. Letzteres ist in Objective-C nicht vorgesehen. Prinizipiell spräche nichts dagegen das in die Sprache einzubauen, wenn man mal von der Designphilosophie der Sprache absieht, wenn es keine Categories gäbe. Categories und Inlining kann zusammen nicht funktionieren. Insofern ist die Diskussion hinfällig.

Siehe zur Sinnhaftigkeit von inline-virtual den Text von MS.

Inlining und Polymorphie kann schon nicht funktionieren, siehe oben den Text von MS.
+++
Tsss, das Wichtigste habe ich vergessen:
Mit Kategorien gibt es zuletzt Probleme. Zwar können Kategorien Methoden überschreiben. Das geht aber schon nur gegenüber den "Originalmethoden" und IIRC ist es dann auch nur tatsächlich so, aber nicht offiziell definiert.

Langer Rede kurzer Sinn: Überschreiben mittels Kategorien ist eigentlich nur etwas fürs Debugging. Alles andere ist eine ganz gefährliche Angelegenheit.

Original von Tom9811
Langer Rede kurzer Sinn: Überschreiben mittels Kategorien ist eigentlich nur etwas fürs Debugging. Alles andere ist eine ganz gefährliche Angelegenheit.

Oh Wahnsinn, es gibt einen Punkt in dem wir einer Meinung sind.

??? Ich benutze nie Kategorien zum Überschreiben.

Sie sind zur Erweiterung gedacht gewesen und da sehr praktisch. So benutze ich sie auch ständig. (Und weiß gar nicht mehr, wie ich ohne sie auskommen soll.)

Original von Tom9811
... a) Die Abschirmung lokaler Properties über Zugriffsmethoden, also ein Verbot, diese unmittelbar über Zuweisung anzusprechen, kenne ich weder in C++ noch in Objective-C, was dieselbe Klasse angeht. Für Subklassen und fremde Klassen kenne ich es in C++ wie in Objective-C (private vs. proteted). Ich sehe hier also weder Unterschied zwischen den Sprachen noch einen Zusammenhang zum Inlining. ...

Es gibt in der Tat ein Bedürfnis nach solch einer strengen Kapselung von Zugriffen auf Properties. Deshalb sind sowohl unter Borland C++ (jetzt auch CodeGear) als auch in Visual C++ derartige Spracherweiterungen vorhanden. Die Sprache C++ selber sieht im Gegensatz etwa zu C# so etwas (leider noch) nicht vor.

Der Zusammenhang zum Inlining besteht nicht direkt über Properties, sondern über LOKAL PRIVATE Methoden, die etwa auch Getter oder Setter sein könnten.

Geht man davon aus, dass es beim Posing gar keine Rolle spielt, wie die Implementierungs-Details einer substituierten Klasse beschaffen sind, so kann man den Aspekt Posing bei nachfolgenden Überlegungen auch einfach ignorieren: betrachte ich also private nicht virtuelle Methoden, so bietet eine späte Bindung dieser Methoden keinerlei Vorteile bei Verwendung innerhalb der Klasse selber, sondern nur unnötigen Ballast wegen einer internen Message-Verarbeitung und der Verunmöglichung von Inline Aufrufen.

Ich hatte mir ursprünglich vorgestellt, dass es bei Objective-C neben (+) für Klassenmethoden und (-) für Instanzmethoden auch die Möglichkeit privater früh gebundener C-Funktionen gäbe, bei denen ein Inline denkbar sei.

Ich hoffte, es sei wenigstens möglich, solche Methoden als normale C-Funktionen etwa deklariert mit einem Zeiger auf eine Klasseninkarnation als erstes Argument gezielt der Source einer Klasse dazuzupacken, wahrscheinlich sogar mit Inline Verwendung, aber die Frage ist, wie kann man diese PRIVAT machen? Hat Objective-C Sprachmittel hierzu? Ich hoffte, Deklarationen zwischen den # eines Interface könnten das leisten, aber Objective-C wird so etwas sicher unterbinden.

Ich sehe dazu kein Bedürfnis, da ich mir nicht vorstellen kann, wie ich versehentlich auf ein Instanzvariable ohne Benutzung eines Setters zugreife. Ich denke, dass ich da im schweren Delirium liegen müsste. Mit Drogen habe ich schon vor Jahren aufgehört.

Original von Tom9811
Ich sehe dazu kein Bedürfnis, da ich mir nicht vorstellen kann, wie ich versehentlich auf ein Instanzvariable ohne Benutzung eines Setters zugreife. Ich denke, dass ich da im schweren Delirium liegen müsste. Mit Drogen habe ich schon vor Jahren aufgehört.

Disziplin ist an keine Sprache gebunden. Oder ist etwa die Verwendung von Objective-C eine solche Droge, die Disziplin aus dem Hut herbeizaubert, einfach durch einen Wechsel der Programmiersprache?

Wenn aber eine Sprache also über Mittel verfügt, sei es generisch oder über Spracherweiterungen, welche solch eine Disziplin formal erzwingen, wie auch z.B. in der Typprüfung in Inline-Funktionen im Gegensatz zu Seiteneffekt gefährdeten Makros, so hilft das doch eher, als dass es schadet.

Wieso also führt es zu solch aggressiven, Panik-geborenen Polemiken, wenn man versucht, die Internas von Objective-C zu hinterfragen? Dies heißt ja nicht, etwas völlig in Frage zu stellen, sondern es zeigt vielmehr Interesse und Bedürfnis nach Antwort.

Es werden also Chancen verpasst, wenn man sich intellektuell derartig in die Drogenszene begibt.

Nein, gegen bewusste Fehler hilft kein Sprachformalismus, sondern Fachkenntnis. Der massiv bösartige Programmierer kann auch das Attribut entfernen.

Eine Sprache soll mich vor versehentlichen Fehlern beschützen.

Wobei es sicher Sprachen gibt, die so komplex geworden sind, dass man mich sogar bewusst schützen muss. Die Lösung scheint mir aber nicht zu sein, sie noch komplizierter zu machen.

Ich verstehe übrigens nicht, warum du mich persönlich angreifst. Hat das einen besonderen Grund oder ist das ganz generell dein Diskussionsstil?

(Wie du jetzt allerdings auf Makros kommst, bleibt mir ohnehin ein Rätsel.)

Original von Tom9811Du erklärst hier, warum es so ist. Das ändert nichts daran das es so ist. Halten wir also fest: In Objective-C gibt es Function-Inlining.

Guck mal in die Apple-Doku:

Symbol, Type, Language
NSMakeRect, Function, C

Na, fällt dir was auf? C. Nicht "Objective-C".

Und vom Inlining von C-Funktionen rede ich hier nunmal nicht.

Und ob du das jetzt schön findest, oder nicht ist mir relativ egal Ich habe nur gesagt das in ObjC Methoden nicht per Inlining "wegoptimiert" werden können. Mehr nicht. Alles weitere ist ebenfalls relativ egal.

Die Geschichte mit dem Inline-Methoden ist doch gegessen.

Ansonsten verstehe ich das nicht. Ich benutze in Objective-C ständig Inline-Funktionen. Ich weiß nicht wie du darauf kommst, dass das etwas mit C zu tun hat. Falls du meinst, dass es in C bereits Funktionen gab, so sei darauf hingewiesen, dass es die schon in B gab. Dann müsstest du also von B-Funktionen sprechen.

Oder liegt es daran, dass du gerade C als älteste Programmiersprache der Familie kennst und deshalb meinst, alles folgende müsse auch gleich C sein? Das wäre aber eine sehr subjektive Sicht der Dinge …