Performancemythen?

minhen

rüdiger schrieb:

Für Stroustrup gehören encapsulation und inheritance auch noch dazu. In der FAQ schreibt er übrigens nur "polymorphism".

Für Xin und mich ebenfalls. Und in der FAQ schreibt Stroustrup zwar "polymorphism", verweist aber auf die "ausführliche Definition" mit "run-time polymorphism" und spricht im restlichen FAQ-Eintrag von virtuellen Methoden.
Weswegen ich auch schon längst bezüglich Laufzeit-Polymorphie bei Stroustrup sagte:

minhen schrieb:

Der dritte Punkt der Definition ist auch mit noch so viel Voreingenommenheit noch immer ziemlich eindeutig. Ohne Voreingenommenheit ist's selbst bei dem an selber Stelle verlinkten FAQ-Eintrag relativ klar.

Bei ... orientiert man sich ja sehr wohl auch an dem Objekt a (man ruft ja nicht B::a auf, sondern A::a). Ob man das nun zu einem Zeitpunkt macht, an dem a existiert oder nicht, ist ja egal.

Nein. Zur Erklärung lese meinen vorigen Beitrag.

Das Problem mit der Unterscheidung zwischen Laufzeit/Statischer-Polymorphie ist einfach der, das man sich von der Implementierung abhängig macht.

Nicht mehr als bei jedem anderem Aspekt einer Programmiersprache, der in irgendeiner Form Verhalten definiert.

struct A {
  void a();
};
A a;
a.a();
Ist ja sehr wohl nach deiner Definition Objektorientiert, wenn ich es mit einem C++-Interpreter ausführe. Genau wie
#include <cstdio>
using std::printf;
class A { };
int printf(A, ...);

int main() {
  printf("hallo welt");
  A a;
  printf(a);
}
Ist in einem C++-Interpreter nach eurer Definition ebenfalls Objektorientiert.

Am Objekt orientiert ist es definitionsgemäß erst, wenn Polymorphie im Spiel ist, die zur Laufzeit aufgelöst werden muss.

Xin

rüdiger schrieb:

Und in Wahrheit eben auch zum Beispiel die Objekt-Orientierung in Lisp durch die Definition erfasst wird.

Xin hatte behauptet, das Multimethoden nicht OOP seien.

"Xin" hat 30 Seiten lang hier sehr viel mitgeschrieben und dabei auch zwei oder drei Flüchtigkeitsfehler gemacht - und klargestellt.

Wenn ich also auf Seite X schreibe, Multimethoden seien nicht OOP, weil ich bei Multimethoden auf Seite X Überladung im Kopf hatte und das auf Seite Y korrigiere und sogar beschreibe, warum Multimethoden auf den gleichen Grundlagen aufbauend OOP sind, wie virtuelle Methoden und beschreibe warum es in C++ keine Multimethoden für Objekte ohne virtuelle Funktionen nicht geben kann, dann solltest Du akzeptieren, dass "Xin" eben nicht behauptet, dass Multimethoden nicht OOP ist.

Das Thema ist durch und solange Du das wieder ausgräbst, zeigt das dass Du Dich ignorant verhältst und nicht an einem produktiven Fortgang der Diskussion interessiert bist.

rüdiger schrieb:

struct A {
  void a();
};
A a;
a.a();
Ist ja sehr wohl nach deiner Definition Objektorientiert, wenn ich es mit einem C++-Interpreter ausführe.
Ansonsten wäre es ja durchaus möglich auch laufzeit-Polymorphie statisch zu erledigen.

Woher soll Dir irgendwer beantworten, wie ein Interpreter das Problem angeht? Wenn hierzu einer eine klare Aussage macht, kann jeder das Gegenteil programmieren, dann sind die Programme aber nicht mehr semantisch identisch.

Wenn der Interpreter das korrekt abarbeitet, ist und bleibt das kein OOP, weil der Code explizit sagt, dass hier kein OOP verwandt werden soll. Sollte Dein Interpreter da OOP draus machen, so hält sich das nicht mehr exakt an die Semantik des Sourcecodes.

Und wen interessiert Dein komischer Interpreter überhaupt?!

C++ ist nicht für als Interpretersprache geschrieben worden und enthält kein Reflection. Arbeitest Du mit C++ Interpretern oder in C++ mit Reflection?!
Das Feature virtual hat eine klar definierte Bedeutung in C++ und wenn jemand mit seinem Interpreter C++ umdefinierst, dann ändern sich eventuell die Antworten auf Deine Frage im Bezug den Beispielcode. Es ist dann aber kein C++ mehr, sondern eine abgewandelte Form von C++, die Deinem Beispielcode eine andere Bedeutung verleiht.

Hat Dein Code eine andere Bedeutung, ändert sich eventuell auch die Antwort, ob der Code OOP ist oder nicht.
Die Definition von OOP ändert sich deswegen nicht.

rüdiger schrieb:

Gestern abend im IRC wollte er, nach dem ich Argumente von ihm zerlegt hatte, den Objekttyp in JS auf einmal anhand der Objekt-Member festmachen...

Da hast Du natürlich recht. Mit Deiner Antwort "ne" auf meine Erklärung hast Du meine ganze Erklärung mit Deinem anschließenden "das stimmt so nicht" richtig auseinandergenommen. Wenn Du was zerlegen willst, musst Du lesen und denken und dann Gegenargumente bringen und diese begründen können.
Ich hatte nicht ein Indiz, dass es bis lesen gereicht hat.

rüdiger schrieb:

Xin schrieb:

DAS sind die Comments, warum ich den Thread noch weiterverfolge.

oder vielleicht eher solche Comments?

"Ich lasse mich nicht auf das Niveau von Beleidigungen herab" - "Du hast Dich hinter meinem Rücken herabgelassen" - "Dich habe auch direkt ins Gesicht beleidigt"

Die Qualität einer Aussage lässt sich an der Dauer ihrer Gültigkeit messen. Diese Deiner Aussagen hattest Du bereits widerlegt, bevor Du sie geschrieben hast.

Ich habe mir die Zitate von mir nochmal durchgelesen und ich stehe hinter jedem einzelnen noch genauso, wie zu dem Zeitpunkt, wie ich sie gepostet habe. Vielleicht fällt Dir auch auf, dass ich nicht auf Dich zutrete und sage "Mann ist der dumm" oder auf Dich losgehe und sage, dass Du sowas von arrogant wärst.
Du hast für die Zitate bis zu meinem ersten Posting in diesem Thread zurückrecherchiert, aber derartige Beleidigungen, wie sie hier reihenweise gegen mich ausgesprochen werden, hast Du vergessen zu quoten?

minhen schrieb:

minhen, wieso schreibst Du hier eigentlich noch?!

Sicher nicht um mich hier irgendwem zu beweisen. Auch nicht um irgendwas zu beweisen. Ist aber in der Tat eine interessante Frage. Nachdem die meisten meiner Beiträge vom Inhalt sowieso eher Fußnoten zu dem sind, was du die ersten 30 Seiten schon geschrieben hast, sag ich jetzt einfach mal Altruismus
(Das ist so natürlich übertrieben. Aber ich denke in die motivationale Richtung geht es tatsächlich.)

So habe ich hier auch angefangen. Wie ich das sehe, haben wir unabhängig voneinander die identische Definition von OOP gefunden und wissen auch warum, weil wir uns mit diesem Thema beschäftigt haben.

Ich kann Dir also mit ruhigem Gewissen, die nächsten 30 Seiten überlassen.

Aber... ich habe am Anfang des Threads definitiv nicht erwartet, dass geistige Horizont vieler der hier Schreibenden nicht weiter reicht, als "Nein" zu sagen und irgendeinen Mist zu äußern und das auch noch dummdreist als Argument zu bezeichnen.

Man kann nicht argumentieren, wenn man die Fehler vorgeworfen bekommt, die das Gegenüber begeht. So werden aus Diskussionspartnern Diskussionsgegner und das ist nicht produktiv.

Ich bezweifle auch, dass Rüdiger irgendwann mal aus seinen Interpretersprachen zurückkehrt und sich Konzepten wie OOP öffnet. Du wirst Dich genauso die nächsten 30 Seiten erklären müssen, warum Du etwas gesagt haben sollst, was Du nie geschrieben hast, laufend darauf hinweisen müssen, dass Du das bereits erklärt hast oder auf Mist einlassen, wie die Multimethoden, die Stroustrups Definition nicht widersprechen, aber trotzdem als knallhartes Argument gegen Stroustrups Definition angesehen wird.

minhen... lass es... es ist Zeitverschwendung. Ich habe Disneys Quote nicht umsonst in meiner Signatur, aber hier zu überzeugen kostet zu viel Zeit und bringt Dir oder mir nichts.

otze

So habe ich hier auch angefangen. Wie ich das sehe, haben wir unabhängig voneinander die identische Definition von OOP gefunden und wissen auch warum, weil wir uns mit diesem Thema beschäftigt haben.

hat sich die gegenseite auch

<°(((><|

Also ich lese diesen thread nun seit 10 uhr heute morgen und bin gerade auf seite 37 angekommen(ca. 1h pause), wie kann man es sich nur so schwer machen OO zu definieren? Diese diskussion hat meinen ganzen sonntag versaut!
OOP ist einfach, dass datein in objekten gelagert sind, und dass man keine globalen variablen für eine bestimmte funktion hat. Jede funktion die man aufruft beschäftigt sich nur mit dem this, und kommuniziert under umständen mit weiteren parameter objekten etc. Sogesen kann man sich die funktion wie ein fließband vorstellen, an dem dann einfach ein objekt ankommt und nur dieses geändert wird, bzw. teilobjekte dazu aufgefordert werden etwas zu machen(außnahme fields, lösung: getter+setter).

Shade Of Mine

Xin schrieb:

Herzen können schlagen, Menschen auch.
Trotzdem besteht zwischen dem Objekt Herz und dem Objekt Mensch keine Beziehung, bei der schlagen() durch eine gemeinsame, überschreibbare Methode beschrieben werden kann.

Ein Herz verhält sich nicht wie ein Mensch. Was du hier beschreibst ist das selbe wie wenn das Inteface TutSchlagen sowohl von Herz als auch von Mensch implementiert wird.

Ein C++ Compiler würde Interfaces übrigens meistens wegoptimieren - das nur so zur Anmerken über die Sinnhaftigkeit von Interfaces - denn sie sind nicht auf jeder Ebene im Code vorhanden. Im abstrakten Design des Programmes - zB UML kommen sie vor. In der Zielsprache auch noch - diese wird dann aber nach C übersetzt und schon sind die Interfaces wegoptimiert. Danach das ganze in Assembler und man findet nicht mal mehr die Andeutung von den Interfaces im Code.

Auf welcher Ebene muss das Interface vorhanden sein damit es als Interface gilt?

In JavaScript denkt man eben anders: man sagt: ich brauche das Interface nicht.

Denken wir mal nach warum man in Java Interfaces braucht: weil es ein strenges Typsystem gibt, dass immer einen Basistypen braucht.
Das ist der Grund für Interfaces in Java. Nicht weil es schön OO ist oder so - sondern eine technische Notwendigkeit.

In anderen Sprachen ohne strenges Typsystem braucht man das Interface aus technischen Gründen nicht mehr. In einigen könnte man es dennoch einbauen - in anderen wo es keine Typen gibt, garnicht.

Die Definition von Polymorphie an einer technischen Notwendigkeit in manchen Sprachen festzulegen halte ich für fragwürdig. In Java geht es nicht ohne Interfaces weil das ein technisches Problem ist. Wenn Interfaces technisch aber nicht möglich sind - zB weil es keine virtuellen Methoden gibt: wozu dann interfaces? Sie garantieren einem ja nur Typsicherheit. Typsicherheit ist in schwach typisierten Sprachen aber Uninteressant.

In JavaScript sind Interfaces unmöglich zu implementieren - die Features der Sprache fehlen komplett. Aber ist Typsicherheit wirklich ein relevanter Punkt für OO Programme?

Man kann nun Argumentieren dass Interfaces nur als Nebenprodukt Typsicherheit bieten sie aber vornehmlich die Relation im Code dastellen. Da komme ich aber wieder zu meinem Punkt:
Es gibt in der Programm Entwicklung massig Ebenen:
Angefangen mit der abstrakten Projetplanung, bis man irgendwann die Features der Software weiß, danach kommt irgendwann mal eine Art UML Diagramm oder eine Skizzierung und dann irgendwann mal der Code. Doch dann ist noch nicht Schluss: der Code wird mehrere male übersetzt bis ihn die CPU verstehen kann.

Welche Ebene definiert nun die Objektorientiertheit. Wenn ich das exakt gleiche UML Diagramm nach Java und nach JavaScript übersetzen lasse - bekomme ich einmal Interfaces (java) und einmal nicht (js).

Ist nun der JS Code nicht Objekt Orientiert aber das UML Diagramm schon? Genau hier liegen meine Probleme. Ich denke: der Gedanke hinter dem Code ist der selbe - der Code ist so ziemlich 1:1 übertragen worden und deshalb ist er, soweit es die Sprachen erlauben - gleichwertig.

Die Relation dass Dynamo eine Energiequelle ist, wird entweder durch ein Interface Energiequelle definiert oder dadurch dass Dynamo alle Funktionen einer Energiequelle implementiert. Natürlich ist die JavaScript Lampe nicht Typsicher. Ich kann ihr alles übergeben - zB ein Fahrrad. Aber das ist eben der Punkt an dynamisch typisierten Sprachen: sie sind in dieser Hinsich unsicher und erlauben dadurch mehr dynamik.

Was in meinen Augen das relevante ist: die Beziehung Dynamo ist eine Energiequelle ist in Gedanken da. Die Sprache gibt mir die Features nicht in die Hand sie im Code direkt zu beschreiben - aber geht es in der OOP wirklich die _Beschreibung_ der Beziehung 2er Objekte? Oder nicht eher um die Beziehung _selber_? Die Beziehung ist ja auch im JS Code da - sie ist lediglich nicht im Code direkt beschrieben - sondern nur in der Doku.

Bei C++ Templates mit Constraints hat man dann auch die Beziehung im Code beschrieben. Dann wird die ganze Diskussion noch lustiger - denn dann schreibt man (ich habe keine Ahnung wie die Constraints Syntax mäßig aussehen werden, deshalb lehne ich mal an Java an):

concept Energiequelle {
  void get_energie();
};
templatey<typename E implements Energiequelle>
class Lampe {
public:
  Lampe(E e){}
};

Plötzlich hat man Typsicherheit - obwohl Dynamo dennoch gleich dem alten ist:

class Dynamo {
public: void get_energie(){}
}
class Atomreaktor {
public: void get_energie(){}
}

Aber Lampe kann nun erkennen ob etwas wirklich eine Energiequelle ist - sprich "Energiequelle implementiert".

Lediglich dass Vererbung nicht nötig ist um eine "is-a" Beziehung dazustellen. Und das ist wieder ein sehr interessanter Punkt: Interfaces verlangen Vererbung - andere Sprachen bietet keine Vererbung: ist nun Vererbung ebenfalls ein zentrales Merkmal der OOP?

BTW, es geht nicht darum ob ich meine Ansichten überdenken sollte: denn ich überdenke sie ständig in Bezug auf OOP. Ich habe keine feste Definition was OOP ist - im Gegensatz zu bestimmten Leuten hier im Thread. Ich weiß, dass ich zuwenig über OOP weiß um sie definieren zu können - ich weiß aber, dass gewisse OOP Definitonen falsch sind, weil sie sich an konkreten Features orientieren. Konkrete Features sind Sprachgebunden und nicht Denkweise gebunden. Und sobald ich einen Programmcode liefern kann der beweist, dass die Definition fehlerhaft ist: was brauch ich mehr?

Ich würde zum Beispiel wenn jemand OOP über Polymorphie definiert nichts dazu sagen - da Polymorphie für mich ein Thema ist, dass ich bei weitem noch nicht ausgelotet habe. Ich kenne zuwenig Arten von Polymorphie und zu wenig Sprachen um zu wissen ob Polymorphie nun essentiell für OOP ist oder nicht.

Ich weiß aber, dass Polymorphie nicht "dynamisch" sein muss (wie mehrfach gesagt: heutzutage kann die Compiletime aber Problemlos während der Laufzeit liegen und somit ist sowieso alles dynamisch) sondern dass es mehrere Arten gibt als "Interfaces".

Ich kann deshalb und werde auch nicht beurteilen ob eine Definition von OOP nun richtig ist - ich weiß aber was OOP nicht definiert. Ich habe in diesem Thread einiges über OOP gelernt. zB Erlang ist wahnsinnig interessant.

Ich lerne ständig dazu was OOP spezifische Features betrifft. In ein paar Jahren haben wir vermutlich wieder andere Features - deshalb verstehe ich nicht wie man sich an einem von den Features orientieren kann.

rüdiger

minhen schrieb:

rüdiger schrieb:

Für Stroustrup gehören encapsulation und inheritance auch noch dazu. In der FAQ schreibt er übrigens nur "polymorphism".

Für Xin und mich ebenfalls.

Gehören sie für Xin wirklich dazu? Wenn ich Formulieren höre, wo er "virtual Functioncall" durch "OOP" ersetzt, glaube ich das fast nicht. Ich kenne nicht alles was Xin geschrieben hat, die letzten 50 Seiten. Aber so wie ich es verstanden habe, macht er ausschließlich OOP an "virtual Functioncalls" fest. Aber vielleicht war das ja auch nur ein Flüchtigkeitsfehler

Bei ... orientiert man sich ja sehr wohl auch an dem Objekt a (man ruft ja nicht B::a auf, sondern A::a). Ob man das nun zu einem Zeitpunkt macht, an dem a existiert oder nicht, ist ja egal.

Nein. Zur Erklärung lese meinen vorigen Beitrag.

Ich finde deine Meinung da einfach nicht einleuchtend. Wir werden unsere Meinung wohl auch nicht zusammen bringen können.

Das Problem mit der Unterscheidung zwischen Laufzeit/Statischer-Polymorphie ist einfach der, das man sich von der Implementierung abhängig macht.

Nicht mehr als bei jedem anderem Aspekt einer Programmiersprache, der in irgendeiner Form Verhalten definiert.

es geht nicht um Verhalten. Es geht um Paradigmen. So kann ich in C++ auch funktional Programmieren, obwohl ich Variablen eigentlich manipulieren könnte. Ihr bezieht OOP auf das Verhalten des Compilers. Ich nicht, absolut gar nicht.

struct A {
  void a();
};
A a;
a.a();
Ist ja sehr wohl nach deiner Definition Objektorientiert, wenn ich es mit einem C++-Interpreter ausführe. Genau wie
#include <cstdio>
using std::printf;
class A { };
int printf(A, ...);

int main() {
  printf("hallo welt");
  A a;
  printf(a);
}
Ist in einem C++-Interpreter nach eurer Definition ebenfalls Objektorientiert.
Am Objekt orientiert ist es definitionsgemäß erst, wenn Polymorphie im Spiel ist, die zur Laufzeit aufgelöst werden muss.

Es wird doch zur Laufzeit aufgelöst und muss von einem Interpreter auch erst zur Laufzeit aufgelöst werden.

Xin schrieb:

Das Thema ist durch und solange Du das wieder ausgräbst, zeigt das dass Du Dich ignorant verhältst und nicht an einem produktiven Fortgang der Diskussion interessiert bist.

minhen hat es ausgegraben. Ich weiß auch nicht, wo du deine Meinung zu Multimethoden revidiert hättest. Habe ich vielleicht übersehen, was bei 50 Seiten ja leicht passieren kann.

Woher soll Dir irgendwer beantworten, wie ein Interpreter das Problem angeht?

Soll mir ja auch niemand beantworten...

Wenn hierzu einer eine klare Aussage macht, kann jeder das Gegenteil programmieren, dann sind die Programme aber nicht mehr semantisch identisch.

Aber natürlich sind sie semantisch identisch. Und was meinst du mit "Gegenteil"? Das sie sich nicht so verhalten, wie du es nach deiner Definition gerne beurteilen würden, ist ja nicht die Schuld des Interpreters. Höchstens die deiner Definition.

Wenn der Interpreter das korrekt abarbeitet, ist und bleibt das kein OOP, weil der Code explizit sagt, dass hier kein OOP verwandt werden soll. Sollte Dein Interpreter da OOP draus machen, so hält sich das nicht mehr exakt an die Semantik des Sourcecodes.

Was meinst du jetzt mit "OOP"? Laufzeit Polymorphismus betreibt er ja.

Und wen interessiert Dein komischer Interpreter überhaupt?!

hmm, vermutlich die Leute die so was programmiert haben oder einsetzen. Aber man kann natürlich einfach alles ignorieren, was einem nicht ins Konzept passt. Da muss man sich dann aber auch nicht über den Vorwurf der Ignoranz wundern.

C++ ist nicht für als Interpretersprache geschrieben worden und enthält kein Reflection.

Natürlich ist C++ nicht für Interpreter entwickelt worden. Aber das hat nichts damit zu tun, das es sie nicht gibt. Templates wurden auch nicht dafür entwickelt um Metaprogrammierung zu betreiben. Aber auch das wird immer stärker betrieben. Nur weil der Erfinder von etwas nicht alle Anwendungsmöglichkeiten vor Auge hat, wenn er etwas erfindet, diskreditiert das ja nicht die alternative Anwendung.

Arbeitest Du mit C++ Interpretern oder in C++ mit Reflection?!

1. Nein
2. Ja

Das Feature virtual hat eine klar definierte Bedeutung in C++ und wenn jemand mit seinem Interpreter C++ umdefinierst, dann ändern sich eventuell die Antworten auf Deine Frage im Bezug den Beispielcode.

Niemand (von mir erwähntes) hat virtual umdefiniert.

Es ist dann aber kein C++ mehr, sondern eine abgewandelte Form von C++, die Deinem Beispielcode eine andere Bedeutung verleiht.

Die Bedeutung des Codes ändert sich ja nicht. Es ändert sich einfach nur die untere Ebene und wenn man unbedingt ein Gedanken-Konzept(!) an die Untere Ebene binden will, dann muss man mit solchen Problemen kämpfen. Daher ist meine Definition auch nicht an die untere Ebene gebunden.

Mit Deiner Antwort "ne" auf meine Erklärung hast Du meine ganze Erklärung mit Deinem anschließenden "das stimmt so nicht" richtig auseinandergenommen. Wenn Du was zerlegen willst, musst Du lesen und denken und dann Gegenargumente bringen und diese begründen können.

Du hättest eben ein Argument bringen sollen. Du hast nur eine Behauptung aufgestellt.

Die Qualität einer Aussage lässt sich an der Dauer ihrer Gültigkeit messen. Diese Deiner Aussagen hattest Du bereits widerlegt, bevor Du sie geschrieben hast.

Du hattest meine Aussage nur falsch verstanden. Sie war sicher nicht eindeutig. Aber ich habe sie ja korrigiert.

Vielleicht fällt Dir auch auf, dass ich nicht auf Dich zutrete und sage "Mann ist der dumm" oder auf Dich losgehe und sage, dass Du sowas von arrogant wärst.

Das "dumm" habe ich ja gestern zurück gezogen. Vielleicht war meine Aussage da nicht lange gültig. Ich halte dich nicht für dumm. Ich halte dich nur für arrogant.

Ich habe mir die Zitate von mir nochmal durchgelesen und ich stehe hinter jedem einzelnen noch genauso, wie zu dem Zeitpunkt, wie ich sie gepostet habe.

Das finde ich sehr schade. Ich dachte du hättest sie vielleicht unter emotionalem Druck gesagt. Aber wenn du darauf beharrst, finde ich es eher traurig für dich.

Du hast für die Zitate bis zu meinem ersten Posting in diesem Thread zurückrecherchiert

Nein nein, ich hab nicht wirklich recherchiert. Ich hab ein paar Sachen aufgegriffen, die ich auf die schnelle gefunden habe. Da ist noch wesentlich mehr...

aber derartige Beleidigungen, wie sie hier reihenweise gegen mich ausgesprochen werden, hast Du vergessen zu quoten?

Das war nie meine Absicht alle hier ausgesprochenen Beleidigungen zu suchen. Ich wollte dir nur interessante Kommentare von dir aufzeigen, damit der Thread immer noch interessant für dich bleibt...

Hier noch ein frischer Kommentar:

Aber... ich habe am Anfang des Threads definitiv nicht erwartet, dass geistige Horizont vieler der hier Schreibenden nicht weiter reicht, als "Nein" zu sagen und irgendeinen Mist zu äußern und das auch noch dummdreist als Argument zu bezeichnen.

Ich bezweifle auch, dass Rüdiger irgendwann mal aus seinen Interpretersprachen zurückkehrt und sich Konzepten wie OOP öffnet.

"meinen" Interpretersprachen? Also Interpretersprachen können jetzt gar nicht mehr OO sein? erstaunlich, erstaunlich

Aber wenn du natürlich gültige Argumente so abspeist (siehe auch oben "Wen interessiert das?!"), dann wundert man sich ja auch nicht über deine Kommentare zu deinen Diskussionspartnern.

wie die Multimethoden, die Stroustrups Definition nicht widersprechen, aber trotzdem als knallhartes Argument gegen Stroustrups Definition angesehen wird.

wird sie das? Du hast behauptet sie widersprechen deiner Definition.

Xin

Shade Of Mine schrieb:

Ein C++ Compiler würde Interfaces übrigens meistens wegoptimieren - das nur so zur Anmerken über die Sinnhaftigkeit von Interfaces.

Ein Compiler kann ein Interface nicht wegoptimieren, da er ansonsten die Semantik des Programms ändert.

Shade Of Mine schrieb:

In JavaScript denkt man eben anders: man sagt: ich brauche das Interface nicht.

In JS hat man das Interface nicht als Sourcecode. Das bedeutet nicht, dass er nicht gebraucht würde oder nicht existieren würde. Du kannst in JS keine Garantie geben, dass sich ein Objekt entsprechend eines Interfaces verhält. In JS kannst Du nur hoffen, dass die Objekte einem Interface entsprechen.
Ein Objekt entspricht einem Interface, wenn es die zum diesem Interface gehörenden Funktionen beschreibt. JavaScript bietet aber keine Möglichkeit dies automatisch zu prüfen.

Shade Of Mine schrieb:

Die Definition von Polymorphie an einer technischen Notwendigkeit in manchen Sprachen festzulegen halte ich für fragwürdig.

Allen Sprachen, bis runter zur Maschinensprache.

Shade Of Mine schrieb:

In JavaScript sind Interfaces unmöglich zu implementieren - die Features der Sprache fehlen komplett. Aber ist Typsicherheit wirklich ein relevanter Punkt für OO Programme?

Typsicherheit ist ein relevanter Punkt für jegliche Form des Programmierens, auch in schwach typisierten Sprachen.

Liest Du einen Datensatz mit dem falschen Datentyp erhältst Du keine sinnvollen Daten.
Wenn this.Data mit "Hallo Welt" initialisiert wurde und Du erwartest den Typ int, dann ist this.Data + 5 nunmal kein Int, bzw. 0. In dem Fall fand eine nicht typsichere Handlung statt und das Programm funktioniert nicht mehr wie sich der Programmierer das vorgestellt hat.
In stark typisierten Sprachen hast Du das Problem nicht, weil die Ausführung bzw. Kompilierung verweigert wird.

Typsicherheit ist eine Voraussetzung für korrekte Programme. Die Kontrolle der Typsicherheit ist keine Voraussetzung für OOP.

Shade Of Mine schrieb:

Welche Ebene definiert nun die Objektorientiertheit. Wenn ich das exakt gleiche UML Diagramm nach Java und nach JavaScript übersetzen lasse - bekomme ich einmal Interfaces (java) und einmal nicht (js).

In JS muss das Programm typsicher sein, ohne dass es durch ein Interface geprüft wird.

Shade Of Mine schrieb:

Bei C++ Templates mit Constraints hat man dann auch die Beziehung im Code beschrieben. Dann wird die ganze Diskussion noch lustiger - denn dann schreibt man (ich habe keine Ahnung wie die Constraints Syntax mäßig aussehen werden, deshalb lehne ich mal an Java an):
concept Energiequelle {
  void get_energie();
};
templatey<typename E implements Energiequelle>
class Lampe {
public:
  Lampe(E e){}
};
Plötzlich hat man Typsicherheit - obwohl Dynamo dennoch gleich dem alten ist:
class Dynamo {
public: void get_energie(){}
}
class Atomreaktor {
public: void get_energie(){}
}
Aber Lampe kann nun erkennen ob etwas wirklich eine Energiequelle ist - sprich "Energiequelle implementiert".

Du kannst Dynamo und Atomreaktor zur Laufzeit nicht austauschen, weil die Programmsteuerung durch den Referenztyp kontrolliert wird und nicht durch den Objekttyp: kein OOP.
Würdest Du virtual verwenden, wäre das möglich - das ist der Sinn von OOP.

Du kannst so zum Beispiel keine Klassen aus Plugins nachladen, wenn Du nur ein "template Plugin" hast. Ohne ein Interface Plugin, geht hier nichts. Aus diesem Grund darf ein Compiler auch nicht ungefragt ein Interface herausoptimieren.

Shade Of Mine schrieb:

Lediglich dass Vererbung nicht nötig ist um eine "is-a" Beziehung dazustellen. Und das ist wieder ein sehr interessanter Punkt: Interfaces verlangen Vererbung - andere Sprachen bietet keine Vererbung: ist nun Vererbung ebenfalls ein zentrales Merkmal der OOP?

Wenn Du allgemeingültige Algorithmen schreiben möchtest, die OOP verwenden ist Vererbung notwendig.
Auch hier ist nicht notwendig, dass die Sprache das kontrolliert, wie in C++. Vererbung ist auch in C oder JS möglich in dem der Konstruktor sicherstellt, dass das Objekt über mindestens die gleichen Eigenschaften verfügt, wie das Basisobjekt.

Shade Of Mine schrieb:

Ich weiß aber, dass Polymorphie nicht "dynamisch" sein muss

Polymorphie muss nicht dynamisch sein. Ob sie statisch oder dynamisch ist entscheidet, ob OOP verwendet wird oder nicht.

Shade Of Mine schrieb:

(wie mehrfach gesagt: heutzutage kann die Compiletime aber Problemlos während der Laufzeit liegen und somit ist sowieso alles dynamisch) sondern dass es mehrere Arten gibt als "Interfaces".

Solange nur zur Laufzeit kompiliert ändert sich nichts. Wird das Programm zur Laufzeit modifiziert, entscheidet sich auch zur Laufzeit, ob ein OOP Zugriff stattfindet oder nicht.

Shade Of Mine schrieb:

Ich lerne ständig dazu was OOP spezifische Features betrifft. In ein paar Jahren haben wir vermutlich wieder andere Features - deshalb verstehe ich nicht wie man sich an einem von den Features orientieren kann.

Natürlich wird es immer neue Features geben. OOP gab's in C++ ja auch bevor es Templates gab. Aber Templates sind nunmal eine andere Baustelle und ändert die Definition von Objektorientierung nicht mehr, zumal Templates sich auch nicht am Typ eines Objektes orientieren, sondern entsprechend eines Typs aufgebaut werden, ohne dass dafür ein Objekt existieren müsste, an dem man sich orientieren könnte.

Xin

rüdiger schrieb:

Ich kenne nicht alles was Xin geschrieben hat, die letzten 50 Seiten. Aber so wie ich es verstanden habe, macht er ausschließlich OOP an "virtual Functioncalls" fest. Aber vielleicht war das ja auch nur ein Flüchtigkeitsfehler

Kein Flüchtigkeitsfehler. Virtual Functioncalls sind exakt, was OOP ausmacht.
Und das schließt Multimethoden ein.

rüdiger schrieb:

Und wen interessiert Dein komischer Interpreter überhaupt?!

hmm, vermutlich die Leute die so was programmiert haben oder einsetzen. Aber man kann natürlich einfach alles ignorieren, was einem nicht ins Konzept passt. Da muss man sich dann aber auch nicht über den Vorwurf der Ignoranz wundern.

Es widerspricht dem Konzept nicht. Ich sehe aber auch keinen Grund hier eine lange Checkliste zu machen, um Dir für jeden Punkt OOP oder Nicht OOP zu sagen. Ich habe das Konzept von OOP beschrieben. Sofern Du es verstanden hast, kannst Du jeden Punkt der Liste selbst beantworten.

rüdiger schrieb:

Mit Deiner Antwort "ne" auf meine Erklärung hast Du meine ganze Erklärung mit Deinem anschließenden "das stimmt so nicht" richtig auseinandergenommen. Wenn Du was zerlegen willst, musst Du lesen und denken und dann Gegenargumente bringen und diese begründen können.

Du hättest eben ein Argument bringen sollen. Du hast nur eine Behauptung aufgestellt.

Ich bin überhaupt nicht dazu gekommen, eine Behauptung aufzustellen, Du hast es schon abgelehnt, bevor ich überhaupt fertig erklärt habe.

rüdiger schrieb:

Hier noch ein frischer Kommentar:

Aber... ich habe am Anfang des Threads definitiv nicht erwartet, dass geistige Horizont vieler der hier Schreibenden nicht weiter reicht, als "Nein" zu sagen und irgendeinen Mist zu äußern und das auch noch dummdreist als Argument zu bezeichnen.

Hehe, ich dachte mir schon, dass das kommt. Aber auch das unterschreibe ich nochmals und Du darfst mich auch gerne in 5 Jahren nochmals fragen.

rüdiger schrieb:

Ich bezweifle auch, dass Rüdiger irgendwann mal aus seinen Interpretersprachen zurückkehrt und sich Konzepten wie OOP öffnet.

"meinen" Interpretersprachen? Also Interpretersprachen können jetzt gar nicht mehr OO sein? erstaunlich, erstaunlich

Ich weiß nicht, wie Du zu dieser Schlussfolgerung kommst, denn das steht da nicht.
Lies Dich über das Konzept OOP ein und Du kannst selbst zwischen OOP und Nicht-OOP unterscheiden - unabhängig ob interpretierende, einfach kompilierend oder mehrfach kompilierende Sprachen.

rüdiger schrieb:

wie die Multimethoden, die Stroustrups Definition nicht widersprechen, aber trotzdem als knallhartes Argument gegen Stroustrups Definition angesehen wird.

wird sie das? Du hast behauptet sie widersprechen deiner Definition.

Junge, Du tickst doch nicht ganz sauber.

Folgendes aus dem Posting, dass jetzt grade mal 3 Stunden alt und ein Reply auf eines Deiner Postings ist:

Xin schrieb:

rüdiger schrieb:

Und in Wahrheit eben auch zum Beispiel die Objekt-Orientierung in Lisp durch die Definition erfasst wird.

Xin hatte behauptet, das Multimethoden nicht OOP seien.

"Xin" hat 30 Seiten lang hier sehr viel mitgeschrieben und dabei auch zwei oder drei Flüchtigkeitsfehler gemacht - und klargestellt.

Wenn ich also auf Seite X schreibe, Multimethoden seien nicht OOP, weil ich bei Multimethoden auf Seite X Überladung im Kopf hatte und das auf Seite Y korrigiere und sogar beschreibe, warum Multimethoden auf den gleichen Grundlagen aufbauend OOP sind, wie virtuelle Methoden und beschreibe warum es in C++ keine Multimethoden für Objekte ohne virtuelle Funktionen nicht geben kann, dann solltest Du akzeptieren, dass "Xin" eben nicht behauptet, dass Multimethoden nicht OOP ist.

Das Thema ist durch und solange Du das wieder ausgräbst, zeigt das dass Du Dich ignorant verhältst und nicht an einem produktiven Fortgang der Diskussion interessiert bist.

Dein erster Satz belegt, dass Du das gelesen hast.
Noch ignoranter geht's echt nicht, rüdiger. Selbst folgendes reicht nicht an Dich heran:

*plonk*

minhen

@Shade of Mine:
Du sagst doch schon selbst, dass dein Wissen womöglich unzureichend ist. Dir fällt auch auf, dass virtuelle Methoden und Interfaces als Laufzeit-Polymorphie nicht brauchbar für eine Definition von OOP verwendet werden können. Aber dass dein Verständnis von Laufzeit-Polymorphie als virtuelle Methoden und Interfaces falsch ist, das kommt dir nicht in den Sinn? Eher ist die entsprechende Definition falsch? Obwohl du sagst, du könntest dir kein Urteil erlauben?
Ich sage es nochmals virtuelle Methoden und Interfaces sind eine Möglichkeit Laufzeit-Polymorphie umzusetzen. Aber Laufzeit-Polymorphie ist deshalb noch lange nicht dasselbe wie virtuelle Methoden und Interfaces. Die Definition von OOP stützt sich jedoch auf Laufzeit-Polymorphie! Und eben nicht auf virtuelle Methoden als konkretes Sprachkonstrukt.

rüdiger schrieb:

Ich finde deine Meinung da einfach nicht einleuchtend. Wir werden unsere Meinung wohl auch nicht zusammen bringen können.

Du musst "meine" Meinung nicht teilen. Wenn du sie aber nicht nachvollziehen kannst, wäre das schlecht. Denn dargelegt wurde sie wirklich deutlich. Ich sehe gerade, dass Stroustrup auch ein C++-Glossar auf seiner Homepage hat. Ich gebe im Folgenden Mal die relevanten Definitionen von Stroustrup an. Das ist alles schon gesagt worden und insofern nicht notwendig. Interessant sind die Definitionen jedoch durch die Verweise auf die entsprechenden Abschnitte in "The C++ Programming language" (TC++PL) und "The Design and Evolution of C++" (D&E) in denen diese Sachen bei Interesse nochmals genauer nachgelesen werden können. Für mich ist damit alles gesagt.

object - (1) a contiguous region of memory holding a value of some type. (2) a named or unnamed variable of some type; an object of a type with a constructor is not considered an object before the constructor has completed and is no longer considered an object once a destructor has started executing for it. Objects can be allocated in static memory, on the stack, on on the free store. TC++PL 4.9.6, 10.4, 10.4.3, D&E 2.3, 3.9.

object-oriented programming - programming using class hierarchies and virtual functions to allow manipulation of objects of a variety of types through well-defined interfaces and allow a program to be extended incrementally through derivation. See also: polymorphism, data abstraction. TC++PL 2.6, 12, D&E 3.5, 7.2.

Aber Achtung:
This glossary is specifically "C++ oriented". That is, it defines terms in the context of C++. For example, it defines generic programming in terms of templates and object-oriented programming in terms of virtual functions, rather than trying to be sufficiently abstract and general to cover all languages and all usages.

Die allgemeine Definition wurde in diesem Thread allerdings bereits mehrfach zitiert. Also nicht den Fehler machen und die C++-spezifischen Auslegungen der allgemeinen Defintion für die allgemeine Definition selbst halten!
Wie gesagt, virtuelle Funktionen und Interfaces sind Mittel für Laufzeit-Polymorphie, aber Laufzeit-Polymorphie ist nicht dasselbe wie virtuelle Funktion oder Interfaces! Sokrates ist ein Mensch, aber nicht alle Menschen sind Sokrates!

es geht nicht um Verhalten. Es geht um Paradigmen. So kann ich in C++ auch funktional Programmieren, obwohl ich Variablen eigentlich manipulieren könnte. Ihr bezieht OOP auf das Verhalten des Compilers. Ich nicht, absolut gar nicht.

Laufzeit-Polymorphie ist ein sprachunabhängiges Konzept und keine sprachabhängige Syntax-Definition. Wenn nicht auf die Syntax, worauf wird sich Laufzeit-Polymorphie dann also wohl beziehen? Überleg mal was die Definition einer Programmiersprache ausmacht. Die Syntax alleine ist es sicher nicht. Denn dann würde es nur Parser, aber keine Interpreter und keine Compiler geben.

Es wird doch zur Laufzeit aufgelöst und muss von einem Interpreter auch erst zur Laufzeit aufgelöst werden.

Dadurch, dass ich auf das Beispiel statischer Polymorphie zur Laufzeit eingegangen bin, wird eigentlich völlig klar, weshalb der Code trotz Interpreters keine Laufzeit-Polymorphie ist. Denn demnach bedeutet Laufzeit-Polymorphie in der OOP-Definition nicht, dass sie spätestens zur Laufzeit erledigt werden muss, sondern frühestens zur Laufzeit erledigt werden kann! Das ist ein bedeutender Unterschied! Und dieser Unterschied ist für die Objekt-Orientierung verantwortlich, dieser Unterschied sorgt für eine scharfe Trennung zwischen statischer und Laufzeit-Polymorphie und dieser Unterschied liegt in der Definition der Programmiersprache selbst (und ist daher auch nicht compiler- oder interpreterabhängig).
Solange die Bedeutung von Laufzeit-Polymorphie und die Abgrenzung zu statischer Polymorphie nicht klar ist, brauchen wir uns auch gar nicht über die Definition von Objekt-Orientierung unterhalten, da diese wegen der Definition von Objekt genau auf diesem Unterschied aufbaut.

Shade Of Mine

Xin schrieb:

Ein Compiler kann ein Interface nicht wegoptimieren, da er ansonsten die Semantik des Programms ändert.

Äh... Das ist aber falsch. Die Semantik ändert sich garnicht wenn er dennoch die richtigen Methoden aufruft.

Beispiel:

class Interface { public: virtual void foo()=0; }
class A : public Interface { public: void foo() {} }
class B : public Interface { public: void foo() {} }

int main() {
  Interface* f=0;
  if(rand()%2) {
    f=new A();
  } else {
    f=new B();
  }
  f->foo();
  delete f;
}

wenn der compiler ein

class A { public: void foo() {} }
class B { public: void foo() {} }

int main() {
  if(rand()%2) {
    a_foo();
  } else {
    b_foo();
  }
}

void a_foo() {
  A a;
  a.foo();
}
void b_foo() {
  B b;
  b.foo();
}

macht ist das aber korrekt. Die Semantik ändert sich nicht.
Auch optimieren C++ Compiler oft virtuelle Methoden aufrufe weg.
Solange sich das Programm immer noch gleich verhält, ergo: korrekte Resultate liefert - kann der Compiler machen was er will.

In JS hat man das Interface nicht als Sourcecode.

Gratulation, das betone ich seit 70 Seiten

Das bedeutet nicht, dass er nicht gebraucht würde oder nicht existieren würde. Du kannst in JS keine Garantie geben, dass sich ein Objekt entsprechend eines Interfaces verhält. In JS kannst Du nur hoffen, dass die Objekte einem Interface entsprechen.

Genau das ist ne ungefähre Definition von dynamischen Typing.

Ein Objekt entspricht einem Interface, wenn es die zum diesem Interface gehörenden Funktionen beschreibt. JavaScript bietet aber keine Möglichkeit dies automatisch zu prüfen.

Und das ist der Punkt:
verlangt OOP Typsicherheit?

Shade Of Mine schrieb:

Die Definition von Polymorphie an einer technischen Notwendigkeit in manchen Sprachen festzulegen halte ich für fragwürdig.

Allen Sprachen, bis runter zur Maschinensprache.
[/quote]
Bestes Beispiel: Java Script hast du bereits selber zugegeben: da trifft diese technische Notwendigkeit (starkes Typsystem) nicht zu.

Shade Of Mine schrieb:

Typsicherheit ist ein relevanter Punkt für jegliche Form des Programmierens, auch in schwach typisierten Sprachen.

Wie kann ich Typsicherheit ohne Typen haben?

Liest Du einen Datensatz mit dem falschen Datentyp erhältst Du keine sinnvollen Daten.

Ja, korrekte Programme muss man auch in dynamisch Typisierten Sprachen schreiben, und?

Typsicherheit ist eine Voraussetzung für korrekte Programme. Die Kontrolle der Typsicherheit ist keine Voraussetzung für OOP.

Also ist der JS Code doch OO?

Über deine Definition von Typsicherheit will ich mal nicht reden...

Shade Of Mine schrieb:

In JS muss das Programm typsicher sein, ohne dass es durch ein Interface geprüft wird.

Ja, das Programm muss korrekt sein - ok. Das setze ich eigentlich immer voraus...

Du kannst Dynamo und Atomreaktor zur Laufzeit nicht austauschen, weil die Programmsteuerung durch den Referenztyp kontrolliert wird und nicht durch den Objekttyp: kein OOP.

Kann ich wohl. Ich nehm einfach einen C++ Interpreter oder eine Bindung von C++ an die .NET/Java VM und schon kann ich es.

Du kannst so zum Beispiel keine Klassen aus Plugins nachladen, wenn Du nur ein "template Plugin" hast. Ohne ein Interface Plugin, geht hier nichts. Aus diesem Grund darf ein Compiler auch nicht ungefragt ein Interface herausoptimieren.

Kann ich Problemlos machen: C++ Interpreter oder Java VM/.NET VM Anbindung und ich kann das machen. Es ist einfach nur ein kleines technisches Problem: nichts konzeptuelles.

Solange nur zur Laufzeit kompiliert ändert sich nichts. Wird das Programm zur Laufzeit modifiziert, entscheidet sich auch zur Laufzeit, ob ein OOP Zugriff stattfindet oder nicht.

Also definiert sich OOP daran welchen Compiler Schalter ich aktiviere?

Mich persönlich interessiert die unterste Ebene vom Code nicht besonders. Was der Compiler aus meinen Code macht ist mir total egal - solange das Resultat richtige Ergebnisse liefert.

Das mit JavaScript habe ich noch nicht verstanden:
wenn ich es nach Java kompiliere, sprich diese Interfaces einbaue - ist es OOP - richtig?
Wenn ich es aber zur Laufzeit interpretiere - ist es dann OOP? Natürlich gehe ich von einem korrekten Programm aus.

rüdiger

Xin schrieb:

rüdiger schrieb:

Ich kenne nicht alles was Xin geschrieben hat, die letzten 50 Seiten. Aber so wie ich es verstanden habe, macht er ausschließlich OOP an "virtual Functioncalls" fest. Aber vielleicht war das ja auch nur ein Flüchtigkeitsfehler

Kein Flüchtigkeitsfehler. Virtual Functioncalls sind exakt, was OOP ausmacht.
Und das schließt Multimethoden ein.

Dann ist deine Definition also anders als die von Stroustrup und Marcus und minhen?

rüdiger schrieb:

Und wen interessiert Dein komischer Interpreter überhaupt?!

hmm, vermutlich die Leute die so was programmiert haben oder einsetzen. Aber man kann natürlich einfach alles ignorieren, was einem nicht ins Konzept passt. Da muss man sich dann aber auch nicht über den Vorwurf der Ignoranz wundern.

Es widerspricht dem Konzept nicht. Ich sehe aber auch keinen Grund hier eine lange Checkliste zu machen, um Dir für jeden Punkt OOP oder Nicht OOP zu sagen. Ich habe das Konzept von OOP beschrieben. Sofern Du es verstanden hast, kannst Du jeden Punkt der Liste selbst beantworten.

Ich verstehe den Sinn deiner Antwort nicht. Ich erwarte keine Liste von dir, ich habe dir lediglich aufgezeigt, was nach deiner Definition ebenfalls als OOP zu verstehen ist. Du kannst nun erklären, warum dies nicht so seien sollte, deine Definition ändern, es hinnehmen oder mich beleidigen, das Argument als uninteressant abtun und sinnfreie Kommentare abgeben. Ich finde es eben schade, dass du die vierte Möglichkeit zu wählen scheinst.

rüdiger schrieb:

Hier noch ein frischer Kommentar:

Aber... ich habe am Anfang des Threads definitiv nicht erwartet, dass geistige Horizont vieler der hier Schreibenden nicht weiter reicht, als "Nein" zu sagen und irgendeinen Mist zu äußern und das auch noch dummdreist als Argument zu bezeichnen.

Hehe, ich dachte mir schon, dass das kommt. Aber auch das unterschreibe ich nochmals und Du darfst mich auch gerne in 5 Jahren nochmals fragen.

Warum schreibst du dann eigentlich noch in diesem Thread oder gar in diesem Forum? Und ist das deine gewöhnliche Art zu diskutieren? (Macht es natürlich auch schön leicht, wenn alle anderen nicht den richtigen Horizont haben, dann braucht man ja gar nicht auf die Argumente einzugehen...)

Lies Dich über das Konzept OOP ein

Ich kenne das OOP Konzept sehr wohl. Wir haben nur andere Definition. Wobei ich meine eben wesentlich besser finde, da ich damit auch Dinge erklären kannst, die du mit "wen interessiert das" abtust.

und Du kannst selbst zwischen OOP und Nicht-OOP unterscheiden - unabhängig ob interpretierende, einfach kompilierend oder mehrfach kompilierende Sprachen.

Das kann ich sehr wohl. Meine Definition erklärt ja auch wesentlich mehr Phänomene als deine.

rüdiger schrieb:

wie die Multimethoden, die Stroustrups Definition nicht widersprechen, aber trotzdem als knallhartes Argument gegen Stroustrups Definition angesehen wird.

wird sie das? Du hast behauptet sie widersprechen deiner Definition.

Junge, Du tickst doch nicht ganz sauber.

Wieder ein Kommentar, der den Thread für dich lesenswert macht?

Folgendes aus dem Posting, dass jetzt grade mal 3 Stunden alt und ein Reply auf eines Deiner Postings ist:

Gut, dann hast du es zurück gezogen. Ich habe es eben nicht gelesen. Steht ja auf Seite Y. Aber gut, wenn dein Posting eine offizielle Zurücknahme seien soll (und auch kein Flüchtigkeitsfehler ist), dann sind wir in dem Punkt wenigstens einer Meinung, das Multimethoden sehr wohl zur OOP gehören.

Noch ignoranter geht's echt nicht, rüdiger.

Doch, man könnte zum Beispiel Argumente ignorieren oder mit einem "Wen interessiert das" abtun...

Shade Of Mine

minhen schrieb:

@Shade of Mine:
Du sagst doch schon selbst, dass dein Wissen womöglich unzureichend ist. Dir fällt auch auf, dass virtuelle Methoden und Interfaces als Laufzeit-Polymorphie nicht brauchbar für eine Definition von OOP verwendet werden können. Aber dass dein Verständnis von Laufzeit-Polymorphie als virtuelle Methoden und Interfaces falsch ist, das kommt dir nicht in den Sinn? Eher ist die entsprechende Definition falsch? Obwohl du sagst, du könntest dir kein Urteil erlauben?
Ich sage es nochmals virtuelle Methoden und Interfaces sind eine Möglichkeit Laufzeit-Polymorphie umzusetzen. Aber Laufzeit-Polymorphie ist deshalb noch lange nicht dasselbe wie virtuelle Methoden und Interfaces. Die Definition von OOP stützt sich jedoch auf Laufzeit-Polymorphie! Und eben nicht auf virtuelle Methoden als konkretes Sprachkonstrukt.

Ich verstehe diese Definition nicht. Warum Laufzeit Polymorphie? Erklär es mir bitte. Und ich verstehe auch nicht, ob der JavaScript Code für dich und Xin jetzt OOP ist oder für euch beide nicht - ihr widersprecht euch zeitweise.

Denn demnach bedeutet Laufzeit-Polymorphie in der OOP-Definition nicht, dass sie spätestens zur Laufzeit erledigt werden muss, sondern frühestens zur Laufzeit erledigt werden kann!

Aber intelligente Compiler können sehr sehr viel zur "Compiletime" feststellen. zB wenn die Kompilierung während der Laufzeit statt findet, hat der Compiler enormes Wissen über den Code und kann da viel optimieren und viele "dynamische" Sachen fest einkompilieren.

Mein C++ Code mit A und B ist ein gutes Beispiel: ein cleverer Compiler der das zur Laufzeit kompiliert kann Anhand von rand() vorhersagen was er machen muss und das fest einkompilieren.

In ein paar Jahren sind die Compiler noch besser - da optimieren sie noch viel viel mehr. Und dann wird es immer schwerer zu sagen was zur Compiletime und was zur Runtime ausgewertet wird. In Java ist diese Trennung bereits fast nicht mehr möglich. In ein paar Jahren wird sie garnicht mehr möglich sein ohne vorher studiert zu haben.

rüdiger

@mihnen
Ich kann deine Argumentation durchaus nachvollziehen. Ich will eben keine Grenze zwischen statischer und dynamischer Polymorphie ziehen. Aber das werden wir wohl selbst in 100 Seiten nicht auf einen gemeinsamen Punkt bringen können und sollten wir vielleicht auch gar nicht.

Es gibt ja eh keinen logischen Grund statische Polymorphie aufzunehmen oder auszuschließen (ansonsten nenne ihn bitte einer, damit wir die Diskussion begraben können! :)).

btw. nach der Stroustrup OO Definition dürfte CLOS gar nicht OO sein, da es keine encapsulation bietet. (Gilt ähnliches nicht auch für JS bzw. dort ist es doch auch nur durch das Scoping möglich?)

Undertaker

minhen schrieb:

object-oriented programming - programming using class hierarchies and virtual functions to allow manipulation of objects of a variety of types through well-defined interfaces and allow a program to be extended incrementally through derivation.

soll das da eine strenge und ganz genaue definition von OOP sein? d.h. alles was nicht all diese punkte erfüllt ist kein OOP?
auch wenn sich obiges einzig und allein auf C++ bezieht, aber das würde ich selbst als nur-C++ -coder nicht akzeptieren. da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'. ich nehme an, der struppi hat sich den text irgendwie aus den fingern gesaugt, ohne 5 min. darüber nachzudenken.

Shade Of Mine

rüdiger schrieb:

(Gilt ähnliches nicht auch für JS bzw. dort ist es doch auch nur durch das Scoping möglich?)

Ja, durch scoping kann man private member anlegen - macht man idR aber nicht.

function Lampe(energiequelle) {
  var e=energiequelle;
  function licht_an_impl() {
  }
  this.licht_an = function() { licht_an_impl() }
}

l=new Lampe()
l.licht_an_impl() //geht nicht
l.e=new Dynamo() //geht nicht
l.licht_an() //geht

Aber was interessant ist: e und licht_an_impl sind nicht bestandteil des prototypes - deshalb macht man es idR nicht.

Es ist eher mehr ein "hack" als designtechnisch eingebaut in die sprache als kapselungshilfe. die function-syntax ist auch eher neu - ursprünglich gab es ja nur prototype-syntax.

rüdiger

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

ich nehme an, der struppi hat sich den text irgendwie aus den fingern gesaugt, ohne 5 min. darüber nachzudenken.

Nein, das glaube ich absolut gar nicht. Nach dem ich einen Vortrag bei Google Talk bei ihm gesehen habe (wirklich guter Vortragender, imho), glaube ich nicht, dass er etwas voreiliges und nicht wohl durchdachtes machen würde. Aber klar, er ist ja kein Halbgott und kann auch mal schwache Tage haben (betont er ja selbst oft genug :))

Nun genug Struppi Fanboyism

rüdiger schrieb:

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

sag ich ja, sieg

was auch lustig ist:

Xin auf seite 34 schrieb:

Lass es mich anders formulieren: Das eigene Hirn zu nutzen bringt mehr, als Texte zu zitieren, ohne zu wissen, ob die jeweiligen Autoren ihr Hirn benutzt haben oder nur von jemand anderem abgeschrieben haben.

aber auf den letzten seiten nur zitate von herrn strostrup

Xin

Shade Of Mine schrieb:

Xin schrieb:

Ein Compiler kann ein Interface nicht wegoptimieren, da er ansonsten die Semantik des Programms ändert.

Äh... Das ist aber falsch. Die Semantik ändert sich garnicht wenn er dennoch die richtigen Methoden aufruft.

Beispiel: [...]
macht ist das aber korrekt. Die Semantik ändert sich nicht.[/cpp]

Witziges Beispiel.
Das funktioniert aber auch nur, wenn garantiert wird, dass die Objektvielfalt beschränkt ist, eine Bedingung, die OOP nicht verlangt. Im Gegenteil - der Zweck von OOP ist ja eben, die Objektvielfalt nicht zu beschränken.
In Deinem Fall beschränkst Du die Objektvielfalt in dem Algorithmus auf A und B.
Wenn das für den Algorithmus reicht, kann es sinnvoll sein OOP aus dem Algorithmus herauszunehmen.

Da nun das Interface fehlt, kannst Du nun keine Algorithmen mehr schreiben, die nur mit Objekten arbeiten, Du musst alles auf A oder B spezialisieren. Und genau das, soll OOP ja vermeiden.

Eine Factory baust Du mit Deinem zweiten Beispiel jedenfalls nicht mehr, ohne böswillig zu casten.
Wenn Du die Funktion main in Factory() umbenennst und sie das erzeugte Objekt zurückgeben lässt, bekommst Du Schwierigkeiten, weil die Objekte ohne Interface nicht mehr verwandt sind.

Weiterhin ist Dein Beispiel ein Punkt, den ein Compiler erstmal erkennen muss, wenn er ihn optimieren will.

Shade Of Mine schrieb:

Auch optimieren C++ Compiler oft virtuelle Methoden aufrufe weg.
Solange sich das Programm immer noch gleich verhält, ergo: korrekte Resultate liefert - kann der Compiler machen was er will.

Wenn er garantieren kann, dass ein Objekt genau einem Typ entspricht - warum nicht. Aber das wird nicht sehr häufig sein.

Shade Of Mine schrieb:

Ein Objekt entspricht einem Interface, wenn es die zum diesem Interface gehörenden Funktionen beschreibt. JavaScript bietet aber keine Möglichkeit dies automatisch zu prüfen.

Und das ist der Punkt:
verlangt OOP Typsicherheit?

Ich quote dann mal aus dem vorherigen Posting:

Xin schrieb:

Typsicherheit ist eine Voraussetzung für korrekte Programme. Die Kontrolle der Typsicherheit ist keine Voraussetzung für OOP.

OOP-Programme reagieren genauso undefiniert, wie andere Programme, wenn Elemente mit dem falschen Typ angesprochen werden.

Shade Of Mine schrieb:

Typsicherheit ist ein relevanter Punkt für jegliche Form des Programmierens, auch in schwach typisierten Sprachen.

Wie kann ich Typsicherheit ohne Typen haben?

Dafür musst Du dann als Programmierer selbst sorgen. Wenn Du Dich vertust, knallt's halt. Die Sprache hat eben nicht die Möglichkeit, Dich vor solchen Fehlern zu warnen.

Shade Of Mine schrieb:

Typsicherheit ist eine Voraussetzung für korrekte Programme. Die Kontrolle der Typsicherheit ist keine Voraussetzung für OOP.

Also ist der JS Code doch OO?

In JS ist überhaupt nichts statisch. Wenn Du das Interface garantieren kannst und damit Objekte austauschbar machen kannst, arbeitest Du objektorientiert.
Ob der JS-Code OO ist, weiß ich nicht, da ich nicht weiß, was der JS-Code ist.

Shade Of Mine schrieb:

Über deine Definition von Typsicherheit will ich mal nicht reden...

Warum nicht? Das liest sich schon wieder wie ein Vorwurf. Genauso wie mir der Satz zuvor 'ich müsse zugeben', mißfällt bei Dingen, die ich nicht bestreite. Ich muss nichts zugeben, ich stimme zu - da besteht ein Unterschied.

Shade Of Mine schrieb:

Du kannst Dynamo und Atomreaktor zur Laufzeit nicht austauschen, weil die Programmsteuerung durch den Referenztyp kontrolliert wird und nicht durch den Objekttyp: kein OOP.

Kann ich wohl. Ich nehm einfach einen C++ Interpreter oder eine Bindung von C++ an die .NET/Java VM und schon kann ich es.

Du kannst so zum Beispiel keine Klassen aus Plugins nachladen, wenn Du nur ein "template Plugin" hast. Ohne ein Interface Plugin, geht hier nichts. Aus diesem Grund darf ein Compiler auch nicht ungefragt ein Interface herausoptimieren.

Kann ich Problemlos machen: C++ Interpreter oder Java VM/.NET VM Anbindung und ich kann das machen. Es ist einfach nur ein kleines technisches Problem: nichts konzeptuelles.

Interpreter, Java und .NET haben das Problem, dass sie selten statisch ablaufen. ^^
Erlaubt C++/CLI überhaupt die übersetzung, ohne ungefragt 'virtual' hinzuzufügen?

Es gibt ja nicht nur die Frage, ob ein Programm OO ist, sondern auch umgekehrt: Welche Möglichkeiten gibt es OO zu vermeiden?

Shade Of Mine schrieb:

Solange nur zur Laufzeit kompiliert ändert sich nichts. Wird das Programm zur Laufzeit modifiziert, entscheidet sich auch zur Laufzeit, ob ein OOP Zugriff stattfindet oder nicht.

Also definiert sich OOP daran welchen Compiler Schalter ich aktiviere?

Hat die Frage etwas mit der Aussage zu tun!?

Wenn Du zur Laufzeit ein Programm B schreibst, dann entscheidest Du zwangsläufig zur Laufzeit des Programms A, ob Programm B OOP verwenden wird oder nicht.

Shade Of Mine schrieb:

Das mit JavaScript habe ich noch nicht verstanden:
wenn ich es nach Java kompiliere, sprich diese Interfaces einbaue - ist es OOP - richtig?
Wenn ich es aber zur Laufzeit interpretiere - ist es dann OOP? Natürlich gehe ich von einem korrekten Programm aus.

Du kompilierst also JavaScripts mit Java...?

Die Antwort auf Deine Frage findest Du bereits in diesem Posting.
Ansonsten gehe ich jetzt die Alarmglocken für besonders qualifizierte Posting abstellen.

Overtaker schrieb:

rüdiger schrieb:

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

sag ich ja, sieg

Ich will euch euren Sieg nicht nehmen. Viel Spaß damit.
Wenn man ihn nur laut genug propagiert, kann man damit sogar amerikanischer Präsident werden.

Overtaker schrieb:

was auch lustig ist:

Xin auf seite 34 schrieb:

Lass es mich anders formulieren: Das eigene Hirn zu nutzen bringt mehr, als Texte zu zitieren, ohne zu wissen, ob die jeweiligen Autoren ihr Hirn benutzt haben oder nur von jemand anderem abgeschrieben haben.

aber auf den letzten seiten nur zitate von herrn strostrup

Ich habe mir seine Argumentationen durchgelesen und mein Hirn benutzt und daraufhin meine Definition von OOP von dem was ihr schreibt auf das was Stroustrup schreibt geändert.
Lustig, nicht? ^^

... Die aufeinander rumhacken, obwohl es mit ein wenig menschenverstand schnell gelöst wär.
Man stelle sich einfach mal ein Treffen zwischen den opponenten vor, die dann sachlich ihre argumente vortragen, und dann verbal z.B. auf etwaigem nicht-beantworten einer frage reagieren und sich nach kurzer zeit einer lösung annähern und diese finden, anstatt 50 seiten gefüllt mit sticheleinen, und teils massiven beleidungen abliefern. Und wenns doch nicht klappt dann kloppen sich halt alle...

minhen

@Shade Of Mine:
Warum Laufzeit-Polymorphie habe ich gerade erst ausführlich beantwortet. Und dass Laufzeit-Polymorphie aus der Definition der Programmiersprache folgt und daher interpretor- und compilerunabhängig ist, habe ich sogar eben erst gesagt.
Du musst natürlich nicht lesen, was ich schreibe. Aber erwarte nicht, dass ich mich ständig wiederhole, nur weil du die Beiträge nicht liest.

rüdiger schrieb:

Es gibt ja eh keinen logischen Grund statische Polymorphie aufzunehmen oder auszuschließen (ansonsten nenne ihn bitte einer, damit wir die Diskussion begraben können! :)).

Es gibt einen Grund statische Polymorphie auszuschließen und das ist die fehlende Orientierung am Objekt. Auch das habe ich mehrmals genannt und begründet. Auch hier werde ich mich nicht ständig wiederholen.

btw. nach der Stroustrup OO Definition dürfte CLOS gar nicht OO sein, da es keine encapsulation bietet.

Ich programmiere nicht mit CLOS. Ich traue Stroustrup jedoch zu nicht einfach etwas zu behaupten, wenn es keine ausreichende Grundlage dafür gibt.

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

Es ist schon klar warum dir ein eher schwammiges Verständnis lieber ist. Schließlich kann man sich dort alles mögliche vorstellen. So funktionieren Definitionen aber nicht.
Stroustrups Definition dagegen ist sehr durchdacht, erfasst Ähnlichkeiten und Unähnlichkeiten solide und sicher, ist präzise definiert und stellt dadurch unterm Strich einen Wissensgewinn dar. Damit leistet diese Definition etwas, was "Nachrichten verschicken" nicht leistet: sie ist praktisch und brauchbar.

Zum Thema Definitionen kann man auch Alan Kay aus dem Jahr 2004 zitieren:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

Man kann also annehmen, dass nach Alan Kay weder C++ noch Java objekt-orientiert sind. Ist das eine brauchbare Definition? Offensichtlich nicht. Sie ist zwar nicht präzise, seinem Verständnis nach aber eindeutig zu speziell. Und insofern hat sie mit der hier oft vertretenen zu allgemeinen Defintion eine Sache gemeinsam: sie erfasst reale Ähnlichkeiten und Unähnlichkeiten nicht brauchbar.