Hallo,

ich komme aus der Java-Welt und möchte mich ein bischen in C/C++ unter Mac OS einarbeiten.
Dazu habe ich ein paar Fragen:
- Hat jemand evtl. ein paar Tips für mich, welche Bücher gut sind? Die Bücher sollten Bäume, Tabellen und Bilder (wie man am besten Bilder in einem Fenster anzeigt) behandeln.
- Unter Microsoft gibt es doch die MSDN für Windows programmierung. Gibt es auch eine Art API/Hilfe für die Mac programmierung und kann man diese evtl. auch irgendwo downlaoden? Da hab ich bis jetzt nicht viel gefunden. Und unter xcode finde ich keine brauchbaren infos, ausser wenns um Objective-C geht.

Ich danke für alle Anregungen.

Gruß

So schnell kann die Zukunft da sein – angeblich ist, wie ich gerade gelesen habe, das neu angekündigte Pixelmator Pro komplett in Swift 4 geschrieben. Pixelmator Pro darf sicher als ernstzunehmendes Programm gelten – man darf also gespannt sein.

Der Punkt ist, dass Du sehr viel persönliche Meinung als absolute Wahrheit darstellst. Soviel wie ich über Softwareentwicklung weiß wirst Du es schwer haben eine Mehrheit der Entwickler von Deinem Standpunkt zu überzeugen.

Übrigens die allererste OO Sprache (Simula! Das ist nämlich älter als SmallTalk) verwendete schon Punkte für den Methodenaufruf. Es gibt so viele verschiedenen Syntaxvarianten um Methodenaufrufe umzusetzen, dass man insbesondere von einen Profi (ich ziele damit auf Dich ab) in der Lage sein sollte das problemlos zu erkennen und umzusetzen.

Was den ganzen Quatsch um es müsse unbedingt Cocoa+Objective-C sein betrifft: Es geht hier wahrscheinlich nur um private Programme bei denen der persönliche Arbeitsaufwand am wichtigsten ist. Wenn man sich hier auf Cocoa festlegt hat man einen klassischen Vendor Lockin und kann bei Bedarf die Programme eben nicht mehr auf anderen Plattformen laufen lassen. D.h. selbst ein Port auf ein andere UNIX kann man vergessen, weil es dafür kein Cocoa gibt. Wer professionell Software verkaufen will bewertet das naturgemäß anders.

Es gibt für UNIX massenweise C++ LowLevel Bibliotheken, die das Leben doch erheblich vereinfachen. C ist nicht wirklich der Weisheit letzter Schluss, weil es sehr viel Handarbeit erfordert. Man kann aber auf LowLevel Sachen mit Python o.ä. zugreifen. Man muss einfach mal den Kontext im Auge behalten hier fragt ein Hobbyist ohne akademische Ausbildung an womit er Programme auf dem Mac schreiben kann, und dann wird ihm hier gleich die Empfehlung gegeben den Weg eines Profi-Entwicklers zu gehen. Hälst Du das ernsthaft für angemessen?

Ich kann Qt wärmstens empfehlen! Man schreibt sauberen C++ Code, und dieser läuft wunderbar auf Mac, Windows, Linux und wen man will sogar Embedded Devices!

Evernote (08.09.2017): We Rebuilt Evernote for iOS in Swift

Nein, danke. Solche Programme sind auf allen Systemen Fremdkörper. Du solltest sagen "laufen". Das wars dann aber auch schon.

Da hast Du ziemlich sicher recht. Aber genau das ist doch mein Punkt: Apple hat sich entschlossen, den hier & heute existierenden Softwareentwicklern nach dem Mund zu reden (die gerne bei der mehrheitlich gewohnten Syntax bleiben möchten), statt aus der Perspektive von Neulingen zu denken – obwohl sie andererseits behaupten, Swift mache es gerade denen besonders einfach. Und das ist eben Quatsch.

Wie gesagt, das war auch Apple-intern Gegenstand heftiger Debatten. Craig Federighi, den ich ohnehin sehr schätze, weiß ich da auf meiner Seite. Ein Compiler-Bauer ist als Autor einer einsteigerfreundlichen Programmiersprache einfach eine komplette Fehlbesetzung.
Dummheiten werden zu allen Zeiten begangen …
Ja, natürlich kann ich das erkennen und umsetzen. Allerdings nicht problemlos, ich muss immer erst zum Medizinschrank gehen und ein blutdrucksenkendes Medikament holen, weil mich diese Art kultureller Ignoranz in pragmatischer Technologie jedesmal erneut so dermaßen aufregt.

Aber ich kann ja auch nicht vernünftig programmieren, wenn das Rechnergehäuse hässlich ist, etwas, was mir aus Deiner Sicht vermutlich ohnehin den Profi-Status nimmt.
Aber gerade Amateuren kann die Cross-Plattform-Fähigkeit doch komplett egal sein? Da ist doch die Befriedigung viel höher, wenn man etwas „richtig Schönes“ maßgeschneidert für „seine“ Plattform erstellen kann.
Nö, gerade die Profi-Entwickler sind es doch, die sich aus kommerziellen Erwägungen um die Plattform-Bindung zu drücken versuchen …
Ja.

Mir fällt da Bill Cheeseman, ein US-Jurist, der sich im Ruhestand mit Verve auf Cocoa + Objective-C als Hobby stürzte und das so begeistert betrieb, dass er sogar ein Einsteiger-Programmierbuch zu dem Thema veröffentlichte.

200% Zustimmung.

Wenn ich lese, Qt-Programme liefen „wunderbar“ auf macOS, weiß ich nicht, ob ich lachen oder weinen soll …

Weinen. Ganz klar weinen. Ich versuche solche, ähhh, "Kunstwerke" möglichst nicht zu benutzen. Auf meinem Job unter Win gibt es das leider öfters. Zuhause habe ich mehr Wahlfreiheit.

Ich empfand das auch als Neuling nie besonders kompliziert oder verwirrend, weil man relativ trivial Methoden von Member unterscheiden kann, letztere haben nun einmal keine Parameter. Mein Einstieg in die OOP Welt erfolgte mit Oberon-2, und keiner C verwandten Sprache.

Die meisten Programmiersprachen folgen der "." Syntax, um sowohl auf Member wie auch auf Methoden zuzugreifen. Im Grunde ist das vollkommen egal. Ich kann auch der Formulierung "man schicke dem Objekt eine Meldung" nichts abgewinnen, weil bei CLOS o.ä. man eben nicht ein Objekt haben kann sondern ganz allgemein mehrere. Es ist die logische Weiterentwicklung, dass man Multimethoden hat und diese abhängig vom Typ mehrerer Parameter dispatched werden. Da funktioniert die obige Formulierung nicht mehr.

Also ich sehe da nicht so den fundamentalen Unterschied
Was mir da immer auffiel, dass Objective-C inkonsequent ist und keine Benennung des ersten Parameters erlaubte. Ich weiß nicht, ob man das nun geändert hat, in Swift scheint es ha der Fall zu sein.
Ehrlicherweise sehe ich meine Rechner nicht, wenn ich am Schreibtisch sitze. Und ich höre ihn nicht, was mir persönlich viel wichtiger ist, da Lärm einem beim konzentrierten Arbeiten wirklich stört. Ich schaue auf Tastatur, Maus, Monitor und diversen Kram der auf dem Schreibtisch steht bzw. liegt unter anderem ein alter Mac Mini. Schön ist der vergilbte Kunststoff der Oberfläche nicht.
Nein, gerade bei Amateuren ist der Zeitaufwand das aller größte Problem. Wenn man sich für eine plattformabhängige Lösung entscheidet, hat man sich auf Gedeih und Verderb an einen Hersteller gebunden. Wenn ich da an meine Apple Karriere zurückdenke, dann gab etliche Brüche bei der man seine private Software hätte jedes mal komplett neu schreiben müssen. Insbesondere wenn man das perfekt in Mac Oberfläche hätte integrieren wollen. Da überwiegt dann der Frust, dass die komplette Arbeit von Apple entwertet wurde und man nicht in der Lage ist, das alte Programm in irgend einer Form auf dem neuen OS laufen zu lassen. Das war wenigstens früher bei Apple noch besser. Aber mit OSX wurde das dramatisch verschlechtert.

Wechsel der Plattform von macOS weg zu UNIX/Linux oder Windows ist dann total verbaut, da es keinen legalen Weg gibt, sein altes Mac Programm auf nicht Apple Hardware aufzuführen. Das gilt analog auch für ältere Mac Programme auf aktueller Mac Hardware.
Wenn man Programme schreiben als Selbstzweck definiert - sicherlich. Zumindest diese Problematik sollte man Hobbyisten verdeutliche und hier nicht in Jubelarien ausbrechen und die negativen Aspekte dieser Entscheidung komplett ausblenden. Denn nur so kann man als Hobbyist eine Entscheidung treffen, bei der man sich nicht bei Apples nächstem Bruch in den APIs grün und blau ärgert.

Erstere manchmal aber auch nicht. Weswegen dann solch syntaktischer Pfusch wie .methode() das Licht der Welt erblickt.

Es geht auch gar nicht darum, ob man etwas bei genauem Hinsehen korrekt und eindeutig verstehen kann. Sondern wie sehr das ohne jede Not gegen natürliches Sprachempfinden gebürstet und dementsprechend zunächst unintuitiv ist. Gewöhnen kann man sich an alles. Aber warum sollte man?
Deswegen sind die meisten Programmiersprachen ja auch syntaktischer Pfusch.
Ob das egal ist, hängt von den Bewertungskriterien ab.
Der Unterschied ist, dass keine einzige natürliche Sprache wie im 1. Fall vorgehen würde, sehr wohl aber wie im 2. Fall. Wie gesagt: Es hängt an den Bewertungskriterien, ob man das als fundamental bewertet oder nicht.
Das ist jetzt sehr lustig, denn es ist aus meiner Perspektive exakt umgekehrt.

Du denkst (aus meiner Perspektive) bereits viel zu sehr mit der Brille herkömmlicher Programmiersprachen, wenn Du Methode und Parameter so strikt unterscheidest, dass Dir die explizite Benennung des ersten Parameters fehlt.

Aber die ganze Idee von Parametern ist hier fehl am Platze. Wenn Du Objective-C einfach als natürlichsprachigen Satz verstehst, ist alles wunderbar:
hat einen wunderbar natürlichen Sprachfluss.

In Swift sähe das so aus:
Hier tauchen wieder diese vermaledeiten Klammern auf, die mitten in einem Satz nichts verloren haben und den Sprachfluss mittendrin unmotiviert zertrennen (zwischen tue und dieses:), während bei undAuchJenes diese Unterbrechung fehlt, also eine semantisch überhaupt nicht zu rechtfertigende Asymmetrie zwischen erstem und zweitem Argument fehlt. Und das Komma stört auch.

Du hingegen wirst vermutlich eher in Swift Symmetrie finden und Objective-C asymmetrisch wahrnehmen. Aus meiner Perspektive liegt das daran, dass Du letztlich in herkömmlichen Funktionen statt in Nachrichten denkst, weswegen Dir die Klammern wohl auch natürlich erscheinen werden.
Da haben wir einfach sehr unterschiedliche Erfahrungen gemacht. Ich habe mein erstes OPENSTEP/Cocoa-Objective-C-Programm 1995 geschrieben, das läuft nach ein paar wenig aufwendigen Anpassungen beim Übergang auf macOS/PPC und dann wieder Intel heute noch wunderbar.
Wer will denn auch von macOS auf Windows oder Linux wechseln?

Was machst Du eigentlich wenn es kein Objective-C mehr gibt? Dauerhaft weinen?

Wir reden über formale Sprachen und nicht über natürlich Sprachen. Letztere sind ohnehin recht unlogisch, und deshalb nicht wirklich dazu geeignet logische Zusammenhänge zu beschreiben. Es hat seine Gründe weshalb in der Mathematik eine eigene spezielle Sprache eingeführt wurde. Philosophen neigen dazu jeder sein eigenes Süppchen zu kochen. D.h. man muss sich zuerst in den meisten Publikationen durch die jeweiligen Definitionen kämpfen, und leichter ist das auch nicht zu lesen: als Beispiel Popper - Logik der Forschung. Das ist alles andere als dem normalen Sprachempfinden entsprechend, obwohl der Text in deutsche Sprache verfasst ist.
Weil eine formale Sprache Fehler bei der Formulierung reduziert und Doppeldeutigkeiten verhindert. Programmcode wird sehr viel mehr gelesen als geschrieben, daher ist es sehr sinnvoll, dass die Leser sofort die Bedeutung erfassen können, und egal welche Programmiersprache ich bisher gesehen habe, sie widersprachen alle dem natürlichen Sprachempfinden.
Das läuft nur wieder auf die Schiene NeXT toll, der Rest bäh. Weniger intellektuell differenzierend geht es nicht mehr?
Weil es nicht das ist worauf es ankommt. Ich habe in meinem Leben etliche formale Sprachen gelernt, sie haben alle ihre Stärken und Schwächen man sollte da einen sprachlichen Aspekt nicht überbewerten. Insbesondere wenn Programme größer werden, sind das nicht die Aspekte die große Probleme aufwerfen. Zudem habe ich den Eindruck, wenn NeXT Ada (ersetzbar durch jede beliebige andere OO Sprache) verwendet hätte, würdest Du das in den Himmel loben.

Der OP hat Erfahrungen mit Java, so dass ihm die Notation, die von Dir so kritisiert wird, nicht unbekannt sein dürfte.
Aus meiner Sicht hast Du Dich mit OO nie weiter auseinandergesetzt, als die Möglichkeiten von Objective-C bieten. Das Dispatching der passenden Methode hängt nämlich allgemein formuliert von den Parametern der Methode ab, und nicht von einem ausgezeichnetem Objekt. Deshalb auch mein Hinweis auf Multiple Dispatch. Die Methodenauswahl sollte beim Lernen von OO die zentrale Rolle einnehmen. Die Objekte sind untergeordnet. Allgemein sollte man OO-Konzepte unabhängig von Programmiersprachen lernen, und dann wissen welche dieser Konzepte man wie in einer bestimmten Sprache benutzen kann. Deshalb ist die konkrete Schreibweise für den Methodenaufruf in Objective-C nahezu belanglos. Wichtig ist, dass man weiß, dass Objective-C einen dynamischen Dispatch mit nur einem Objekt beherrscht. Das ist für das OOD wichtig.

Es ist unlogisch und ein Fehler in der Sprachdefinition, weil eben in Objective-C Parameter nicht nach Typ unterschieden werden, sondern Namen des Parameters. Aber eben nicht wenn die Methode nur einen Parameter hat, dann muss der Methodennamen trotzdem geändert werden. Den logischen Bruch siehst Du nicht?
Ich habe das gemacht, weil mich die unter OSX ständigen Compileorgien irgend wann angeko*** haben. Ich brauche nun einmal viele Softwarepakete, die es bei Linux in den Standarddistributionen gibt, so dass ich sie nicht selbst pflegen muss. Unter macOS müsste ich dann andere Quellen nutzen. Meine Erfahrung damit ist nun einmal, dass man dann einen erheblichen Eigenanteil an Arbeit hineinstecken muss.

Meinen Mac habe ich ja auch noch, aber >90% mache ich nur noch unter Linux und es funktioniert bestens. Für den Rest entweder Wine oder VirtualBox und da fehlt mir ehrlich gesagt eher Windows als macOS, weil es vieles weder für Linux noch macOS gibt.

Warum sollte ich mir Gedanken über Dinge machen, die ohnehin nicht eintreten werden?

Im übrigen wäre es nicht meine Art, mich kritiklos dem Mainstream zu beugen und meiner Überzeugung nach Kritikwürdiges nur deshalb nicht zu kritisieren, weil ich meiner Einschätzung nach die Mehrheit gegen mich habe. Think different.

Das ist schon klar, aber kein Grund, aus Gedankenlosigkeit oder geistigem Phlegma heraus ohne Not natürlichsprachig kontraintuitive Konstrukte zu wählen.

Klar sind Programmiersprachen formalisiert. Dass der Versuch, eine Programmiersprache zu sehr an natürliche Sprachen anzulehnen, grässlich schiefgehen kann, dafür ist AppleScript ja ein gutes Beispiel.

Darüber hinaus habe ich aber mit der Swift-Syntax eben das spezifische Problem, dass in ihr die Implementation (Methoden werden durch Funktionsaufrufe implementiert) sehr klar durchscheint, und das widerspricht für mich eklatant der OO-Grundidee der Kapselung.

In Objective-C ist die Trennung zwischen der („natürlichsprachigeren“) OO-Syntax und der („klassischen“) prozeduralen Syntax hingegen augenfällig und überhaupt nicht zu verwechseln.
Objective-C tut das aber eben in einem viel geringeren Maße und ist dennoch syntaktisch vollkommen eindeutig.

Und eben weit weniger doppeldeutig als Swift, was die Differenzierung von OO und prozeduralem Code angeht.

Die mangelnde Klarheit ist ja gerade ein Hauptkritikpunkt von mir an Swift.
Ich kann doch nix dafür, wenn so Vieles bäh ist (nicht alles außer NeXT, das habe ich nie gesagt). Wäre mir ganz sicher lieber, wenn das nicht so wäre.
Ja, nach Deinen Bewertungskriterien. Nach meinen eben schon. Mehr sage ich doch gar nicht.
Nö, überbewerten sollte man das – wie das Wort schon sagt  – nicht (ich habe oben selbst geschrieben, dass die Cocoa-API viel wichtiger ist als die Frage Objective-C vs. Swift). Aber bewerten.
Nö, das war umgekehrt – ich fand NeXT insbesondere auch wegen Objective-C toll.
Das stimmt, und ich gebe gerne zu, dass sich unsere Auseinandersetzung über Sprache an dieser Stelle längst verselbständigt hat und nicht mehr im Sinne des OP ist.
Guter Punkt.
Nö. Ich verstehe auch nicht ganz, was Du meinst. Im Falle von tueDieses:undAuchJenes: ist genau das ja der Methodenname, und nicht etwa nur tueDieses:. Wenn sich etwas ändert, muss also immer der Methodenname geändert werden – logisch und konsistent.
Wenn das Dein Arbeitsschwerpunkt ist, ergibt das ja auch Sinn.

Meine diesbezügliche Bemerkung trug einen Smiley.

Nur mal zur Info:

Native Instruments Programme z.B. Traktor haben Qt unter der Haube. So auch Spotify, VirtualBox, Open Broadcaster, Skype, Parallels Desktop, Scribus, TeamViever, Telegram ... uvm.

Das sind bestimmt alles ganz schlechte Programme die furchtbar unter OSX laufen, oder?

Das sehe ich nicht so. Denn das müsste tueDieses mit Objekt A und den Parametern B und C heißen. Das übersetzt sich zu
Bessere sähe das natürlich so aus

Nicht zwingend. Aber sie verhalten sich einfach nicht so. VirtualBox ist vollkommen gruselig.

Was soll denn da gruselig sein? Ich benutze virtualbox fast täglich und das Programm und dessen GUI tut genau was soll.

In der Tat.

Schön das es das tut. Man merkt dennoch, dass es nicht nativ ist.

Müsste es nicht. Es wird nicht mit dem Objekt etwas getan, sondern ich sende dem Objekt eine Nachricht, dass es bitte etwas tun soll.
Aber warum? Es ist doch unmittelbar augenfällig, dass hinter dem ersten Doppelpunkt nichts steht und auch nie etwas stehen würde. Der Doppelpunkt ist an dieser Stelle völlig fehl am Platze. Und wieso mit? Ist das Programmier-Kanaksprak ?

Alter schließtDuFenster: mit:rechtesFenster! <schauder/>
  Und das finde ich natürlich nur noch gruselig …

Alter.schließtDuFenster(mit:rechtesFenster) <schauder/>

Da schreit Dich die prozedurale Implementation dahinter doch förmlich an …

Eine Variante, die meinen Magensäurespiegel nicht in ungesundeste Höhen katapultiert, kann nur etwa so lauten:

Alter schließeBitteDasFenster:rechtesFenster

Ja. Es kommt auch auf das "wie" an. Du kannst Dich z.B. bei Virtual Box nicht durch alle Steuerelemente durchtabben. Nur durch die, die scheinbar vom System durchgereicht werden.

Den Punkt hatten wir doch schon. Das ergibt bei Multimethoden keinerlei Sinn. Daher kann die allgemeine Formulierung nur lauten: Die Methode macht mit den Objekten folgendes …
Denn wenn man zwei oder mehr Objekte hat, wie schickt man dann an ein Objekt ein Message?

Dann kommt noch der Punkt dazu, wie man Methoden mit dem gleichen Namen und gleicher Anzahl an Parameter unterscheidet. Das übliche ist, man nimmt den Methodennamen und die Datentypen zur Unterscheidung. Objective-C setzt hierfür auf Namen und nicht Typen.
Das ist das was bei Dir im Kopf abläuft. Nein, das ist nicht prozedural wenn dort steht
sondern dort steht nur, dass eine Funktion/Methode "foo" drei Parameter (A,B,C,) übergeben werden. Es geht natürlich auch der CL Style
Wie bereits beschrieben ist das alles nur Syntax

Ja. Aber weder Objective-C noch Swift kennen Multimethoden, und Dein Beispiel enthielt auch keine.
Das ergibt aber genauso wenig Sinn. Eine Methode macht von sich aus gar nichts. Sie ist das Prädikat. Wer ist das Subjekt?
Zwei mögliche, mit Objective-C kompatible Varianten wären z.B.:

Instanzmethode:
Klassenmethode:Zu recht, schließlich kennt Objective-C von Haus aus keine Typen, die wurden ja nur für Dummies nachträglich aufgepfropft.
Na und? Alles läuft beim Programmieren im Kopf ab. Und wenn es nun Entwicklern mehrheitlich so geht? Dann rutschen sie mehrheitlich in eine falsche Perspektive.
Und das ist prompt ein gutes Beispiel dafür: Wie kann man nur Methoden und Funktionen in einem Atemzug nennen? Das ist was vollkommen Unterschiedliches.
Worum wir streiten, ist das Wörtchen nur. Nach meiner Erfahrung mit Code, den ich von anderen übernommen hatte und erstmal überarbeiten musste, ist das Denken in prozeduralen Mustern in einem OO-Programm eine der Hauptursachen für schlechten Code. Ob einem die Syntax dieses Denken nahelegt oder gerade nicht, kann da einen erheblichen Unterschied machen.

Meine persönliche Vermutung ist, dass eine der Hauptursachen für die Klagen über Objective-C ist, dass diese Sprache es einem viel weniger leicht durchgehen lässt, de facto eben doch prozedural zu denken und zu programmieren. In C++ hingegen kann man wunderbar vorgeben, OO-Code zu schreiben, ohne es wirklich zu tun.

Ich habe die Methoden nicht weiter ausgeführt. Es geht mir aber um eine allgemeingültige Sprache, um OO Aspekte zu beschreiben. Da passt es dann nicht, wenn man von Nachrichten an Objekten spricht.
Schon wieder: "das Subjekt" existiert dann eben nicht! Es gibt Objekte und eine darauf operierende Methode.
Das funktioniert so nicht, denn hier ist ein Objekt besonders ausgezeichnet, nämlich Objekt A. Überhaupt wie implementiert man die Methode foo, wenn A, B und C aus unterschiedlichen Klassenhierarchien (da es in Objective-C eine gemeinsame Basisklasse gibt, wären das unterschiedlichen Teilbäume der globalen Klassenhierarchie) stammen? Die Methode foo muss also außerhalb der Klassendefinition von der Klasse von A, B bzw. C definiert werden. Dann braucht man so etwas wie ein Module/Package in dem die Klassen und die Methode foo definiert werden.

Das ganze nachfolgend in einem C++ angelehnten Pseudocode
Dann wird jeweils eine der vier Implementationen von foo abhängig von den beiden Parametertypen aufgerufen. Es ergibt in diesem Kontext wenig Sinn foo innerhalb der von TAbase abgeleiteten Klassen zu implementieren, wie Dir das vorschwebt.
Versuche wenigstens nachzuvollziehen, weshalb Dein Standpunkt in diesem Kontext von Multimethoden so problematisch ist.
Es ist genau genommen das gleiche! Es ist doch vollkommen belanglos, ob man null, einen oder mehrere Parameter einer Prozedur/Funktion/Methode dispatched. Eine Prozedur ist eine Methode, bei der eben alle Typen statisch während der Compilezeit aufgelöst werden können.

Auch die klassischen eingebauten Typen sind implizite Klassen, da es eben nicht nur PODs sind sondern auch "Methoden" für diese PODs existieren.

Beispiel short und int:
Es gibt die eingebauten Operatorn: + - * / = …
Es gibt Konversionen, verlustfrei von short zu int, …
Die "Methoden" werden wegen der Performance nicht dispatched. In C++ und vielen anderen OO Sprachen kann dieses Verhalten auch für eigenen Klassen nachbilden, damit man zwar Klassen hat, aber keine Nachteile bei der Performance. Objective-C folgt einem dogmatischen Ansatz, der von solchen pragmatischen Lösungen nichts hält. Da ist man halt auf C limitiert, wenn man schnellen Code benötigt.Entweder man hat OO verstanden oder nicht, da hilft die Syntax nicht wirklich weiter.
Der Punkt ist, Objective-C kennt nur einen Ansatz für OO und damit muss man alle OO Abläufe umsetzen, oder man fällt auf C zurück.

Aber das ist semantisch widersinnig. Es gibt keine Prädikate ohne Subjekte. Nichts auf der Welt geschieht „von selbst“.
Ds ist natürlich richtig. Mein anderer Vorschlag (Klassenmethode) ist in der Regel daher wohl besser.
Das ist ein weiteres gutes Beispiel für unsere unterschiedliche Sichtweise: Du denkst von der Implementation her, ich von der Semantik.
Ich vermute, der Satz beschreibt unseren unterschiedlichen Blick auf diese Fragen im Kern recht gut, denn ich gehe davon aus, dass das für Dich ein negatives Merkmal von Objective-C ist. Für mich ist es gerade einer der Punkte, warum ich Objective-C so mag.

Jaja... nicht jeder versteht und mag das Dynamic Linking von Objective-C. Auch ich liebe es.

Da wird nicht von einer Klasseninstanz eine Methode einer anderen Klasseninstanz mit der Adresse, die beim Kompilieren und Linken festgelegt wird, aufgerufen. Statt dessen, schickt man von einer Klasseninstanz eine Nachricht an eine andere Klasseninstanz: "Hallo Objekt, könntest du bitte die Methode mit folgenden Argumenten ausführen?". Der Unterschied mag gering erscheinen, aber es steckt mehr dahinter. Ein Objekt kann während der Laufzeit neue Methoden "lernen". Oder man kann Objekte zur Laufzeit austauschen, solange sie die Methode anbietet. Insgesamt eben eher SmallTalk und das folgt einem ganz anderem Schema.

Was übrigens die Übersichtlichkeit wesentlich erleichtert: in Objective-C gibt es keine Multi-Inheritance.

Du drehst Dich immer um dasselbe Problem, und willst nicht wahrhaben, dass eine OO Welt außerhalb von Objective-C gibt. Multimethoden sind eher die Domäne von Common Lisp und nicht von C++. Daher nicht krampfhaft an dem Vergleich mit C++ festhalten, das ist in diesem Kontext nicht sinnvoll.
Das information hiding ist ein zentrales Element von OO, wie willst Du das denn umsetzen? Eine Klassenmethode hat keinerlei Kenntnis von Exemplaren einer Klasse, es kann also mit diesen gar nicht korrekt umgehen. Wie soll das funktionieren, wenn wie oben beschrieben TAa und TBa zwei vollständig unterschiedlichen Klassen sind, die nicht voneinander erben? Auch hier gibt es keinerlei Möglichkeit das korrekt umzusetzen. Man müsste das innere der Klassen über Methoden zugänglich machen, was man aber in den meisten Fällen gar nicht will. Internas sind Internas und gehören nicht in das Interface einer Klasse verlagert.

Mit dem von mir skizzierten Weg, dass man das information hiding per Module steuert hat man das Problem nicht, und dann werden Methoden freistehend umgesetzt. Nichts anderes ergibt rein logisch einen Sinn, denn die vorher angesprochene Methode foo gehört weder zu TAa, TAb, TBa oder TBb! Die Methode gehört zu mehrere Klassen.

Du kannst gerne nachlesen wie das Common Lisp, Julia, Dylan, … umsetzt, und wie man das dort formuliert. Dylan sollte man als Apple Kunde kennen, aber Du kennst Apple ja erst seit dem NeXT Apple übernommen hat.
Nein, es geht rein um Logik. Weshalb wird künstlich bei den Aufrufen unterschieden (Du willst partout einen Unterschied der Implementation sichtbar machen!), wie viele Parameter einer Funktion/Prozedur/Methode dispatching auslösen? Wenn man das allgemein betrachtet, dann gibt es die Möglichkeit, dass Null, Ein oder Viele Parameter das Dispatching bewirken. Was ist daran sonderbar?
Dein Problem scheint zu sein, dass Du außer C++ und Objective-C nicht viel mehr kennst. Es gibt eine Welt abseits dieser beiden Sprachen. Objective-C ist ziemlich übler Hack, und nur wegen der damaligen Zeit so geworden wie es ist. Es folgt nämlich einem ähnlichen Ansatz wie C++. Man sollte sich noch einmal durchlesen, weshalb Stroustrup C++ entworfen hatte. Simula war einfach viel zu langsam. Das gleiche Problem existierte bei SmallTalk, so dass Objective-C entworfen wurde. Nicht ohne Grund wurde C als Basis von Objective-C gewählt, weil Performance eben ein ganz reales Problem war. Die Eleganz von SmallTalk besitzt Objective-C eindeutig nicht, weil die Altlast C dran hängt.
Das haben etliche andere Programmiersprachen ebenfalls, und der Begriff Dynamic Linking ist ebenfalls nicht optimal. Duck Typing trifft es eher, was Du meinst.
Es gibt Multiple Inheritance für Arme - Interfaces, und auch das hat Konsequenzen.

Öhm – ich habe an dieser Stelle überhaupt nicht über die OO-Welt gesprochen. Ich habe über die Welt gesprochen, den Kosmos, das Universum, das Ding, in dem wir leben. Und in dem gibt es nirgendwo ein Prädikat ohne Subjekt. Und da ich an OO-Sprachen den Anspruch habe, dass sie versuchen, diese Welt zu modellieren, darf es bei einer gelungenen OO-Sprache aus meiner Sicht eben auch keine Aktion ohne Aktor geben.
? Von C++ habe ich überhaupt nicht gesprochen – das warst Du.
Aber was heißt das? Wer ist dann der Urheber, der diese Methode ausführt?
Aber “dispatching” ist ein Begriff, der die Implementation beschreibt. In der realen Welt, die modelliert werden soll, gibt es kein “dispatching”.

Daher bist aus meiner Sicht Du derjenige, der über die Implementation spricht.
Keine Ahnung, wieso Du meinst, dass ich C++ gut kenne. Ich kenne einige Sprachen gut, aber C++ gehört nicht dazu. Und hier ging es um Swift.
Richtig, es gibt insbesondere die Welt abseits dieser beiden Sprachen.
So unterschiedlich kann das Verständnis von „Eleganz“ ausfallen. Aus meiner Sicht ist die fugenlose Kombination aus der low level lingua franca des Programmierens und einer die reale Welt adäquat modellierenden OO-Semantik so ziemlich das Eleganteste, was ich mir vorstellen kann. Sprich, für mich ist Objective-C definitiv eleganter als SmallTalk (und C auch ganz sicher keine Altlast).

Der Thread im dem der Programmcode ausgeführt wird ist der Akteur. Wer sonst führt den Programmcode aus? Daher können im Programmcode immer nur Objekte stehen, mit denen der Thread irgend etwas macht. Wenn man es formaler ausdrücken will, wendet der Thread Operatoren auf Objekte an.
Es gibt zwar in der realen Welt kein Dispatching, aber wir reden bei der OOP über bestimmte Konzepte, die allen Sprachen gemein ist. Daher ist Dispatching ein Teil des OODs, und dessen konkrete Umsetzung ist dann eine Frage der Implementation. Wie das alles zusammen hängt kann man etwa bei Booch nachlesen. Sein OOA&OOD Buch ist Standardliteratur.
OOD ist keine Implementation sondern nur der Rohentwurf eines Programms und zudem noch vollständig unabhängig von irgend einer Programmiersprache.
C ermöglicht es schwerste Sicherheitslücken in Programme einzubauen und man muss sehr diszipliniert sein, um solche Fehler zu eliminieren. Man sollte schon sehr gute Gründe haben überhaupt noch C zu verwenden, i.d.R. sollte man grundsätzlich auf C verzichten. C ist auch Sicherheitssicht sozusagen die Ausgeburt der Hölle.

Und wieder argumentierst Du in IT-immanenten Termini. Die Pointe von OO-Programmierung ist es aber, die reale Welt adäquat modellieren zu können.

In die reale Welt übersetzt wäre „der Thread“ sowas wie ein Gott. Um diese Modellierung plausibel zu finden, bin ich nicht religiös genug. Ich sage meinen Objekten lieber, was sie tun sollen, und die tun das dann selbst. Das entspricht meiner Weltwahrnehmung weit eher – und führt deshalb auch zu Realwelt-kompatibleren Programmen.
Du tust immer so, als lägen unsere Differenzen darin begründet, dass mir Informationen fehlen, die Du hast. Das ist aber nicht der Fall. Ich habe einfach andere Präferenzen.
Vielleicht sind wir ja hier an des Pudels Kern angelangt. Ich liebe C, und Du ganz offenkundig nicht.