Performancemythen?

@das...: Du nervst.

Lasst die Mythen selbiges sein.

merker schrieb:

Shade Of Mine schrieb:

Eine Beziehung muss nicht direkt im Soucrcode vorhanden sein. Denn SourceCode ist nur eine Ebene - (...).
Weiters ist der Source Code ja auch nicht die oberste Ebene: es gibt diverse Planungstools, UML oder Gedankengänge die Ebenen höher als der Source Code liegen.

Wo genau muss nun die Beziehung direkt im Code stehen - wo setzt man die gültige Ebene an?

Unsere Behauptung ist nun: diese Beziehung muss im Geiste da sein und das Programm muss nach dieser Beziehung modelliert werden.
Ob diese Beziehung nun als Interface im Code vorkommt oder nicht, ist nach unserer Definition implementationsabhängig - ändert aber nichts an dem Gedanken hinter dem Code.

Was bedeutet dann aber das "P" in OOP ? Planung ?

Steht zwar immer noch für Programmierung, aber wie Du vielleicht nicht weisst ist Programmieren mehr als nur Code in einen Editor zu hacken. z.B. gehört die Designphase ebenso zum Programmieren wie die Implementierungsphase.

Die Folgerung daraus ist, wenn Programmierung mit dem Design einer Software beginnt und der spätere Code nur die Implementierung des Designs ist, dann müßte sich OOP bereits in der Design-Phase erkennen lassen. Anders gesagt, dann gibt es wohl tatsächlich so etwas wie OOD(esign) (Design=Planung). Oh, und siehe da, ja, das gibts wirklich: http://de.wikipedia.org/wiki/Objektorientiertes_Design

Ist schon blöde wenn man klugscheissen will und dann leider voll danebenhaut

nix merker schrieb:

Steht zwar immer noch für Programmierung, aber wie Du vielleicht nicht weisst ist Programmieren mehr als nur Code in einen Editor zu hacken.
z.B. gehört die Designphase ebenso zum Programmieren wie die Implementierungsphase.

Du hast noch nie in einem Team an ca. 0.5 Mio Programmzeilen gearbeitet.

Einer für Alles gibt es nur noch bei den Drei Musketieren.

minhen

rüdiger schrieb:

Ich finde es eben nur unverständlich, dass du auf eine Frage einfach deine Definition hinklatschst. Die kenne ich bereits. Mir ging es um die Motivation dahinter. Das war übrigens das zweite mal in diesem Thread.

Das hört sich doch schon anders an. Du hast behauptet, Stroustrup hätte nichts derartiges gesagt. Ist klar dass ich darauf erst einmal mit einem entsprechendem Zitat antworte, welches diese Behauptung widerlegt. Das Umfeld der Definition sollte auch helfen klarzumachen, dass ein Teil der Kritik hier wirklich auf ein Unverständnis der Allgemeinheit der Konzepte zurückgeht. Und in Wahrheit eben auch zum Beispiel die Objekt-Orientierung in Lisp durch die Definition erfasst wird. In diesem Sinn steht das Zitat also auch im Kontext dessen was ich zu "Shade of Mine" schon sagte.
Zur Motivation warum ausgerechnet Laufzeit-Polymorphie in der Definition sinnvoll ist, fasse ich mal zusammen. Ein Objekt ist eine konkrete (Speicher-)Ausprägung. Im Fall von Klassen sind Objekte also die Instanzen der Klassen. Daraus ergibt sich bereits die besondere Bedeutung einer Polymorphie, die zur Laufzeit stattfinden muss. Denn eine solche Polymorphie hat zwingend das Objekt, also die konkrete Ausprägung, zum Mittelpunkt an dem sie sich orientiert. Bei explizit typisierten Sprachen also eben nicht den Typ der Variabel, über die man das Objekt zufällig anspricht, sondern wirklich den Typ des Objekts selbst. Ein Motorrad verhält sich also zum Beispiel auch wie ein Motorrad auch wenn und obwohl ich es als Fahrzeug anspreche. Bei Polymorphie-Formen, die nicht zur Laufzeit stattfinden müssen, benötigt man dagegen keine konkrete Ausprägung, also auch kein Objekt, und kann sich daher auch nicht am Objekt orientieren. Die besondere Bedeutung einer Polymorphie, die zur Laufzeit stattfindet, ergibt sich für Objekt-Orientierung also bereits von alleine aus der Definition von Objekt.
Laufzeit-Polymorphie ist demnach im Gegensatz zu anderen Techniken ganz klar objekt-orieniert. Und das ist die Motivation es zu einem Definitionskriterium für Objekt-Orientierung zu machen.

Hier passt es vielleicht auch ganz gut noch schnell auf die Argumente bezüglich des hypothetischen Gedankenspiels "statische Polymorphie zur Laufzeit zu erledigen" einzugehen. Man kann selbstverständlich auch ohne Zwang Dinge in die Laufzeit verlegen. Wenn dies aber nicht notwendig ist, würde man - auch wenn die ersten beiden Definitionskriterien erfüllt sind - trotzdem nicht von einer objekt-orientierten Sprache sprechen. Denn die Objekt-Orientierung folgt dann auch nicht aus der Sprache selbst, sondern aus der Technik, die sich entschieden hat, Nicht-Objekt-Orientiertes objekt-orientiert zu implementieren. Erst wenn die Sprache die oben beschriebene Objekt-Orientierung erzwingt (oder erzwingen kann - man muss OO ja nicht immer nutzen), kann auch die Sprache selbst sinnvoll als objekt-orientiert bezeichnet werden.

Xin schrieb:

Meine Definition von Objekt ist alles außer void.
Meine Definition von Objekttyp ist der Datentyp des Objektes.
int a;
ist ein Objekt, der Objekttyp ist int.

Ja, das hört sich sehr nach Stroustrup an.

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.)

rüdiger

minhen schrieb:

rüdiger schrieb:

Ich finde es eben nur unverständlich, dass du auf eine Frage einfach deine Definition hinklatschst. Die kenne ich bereits. Mir ging es um die Motivation dahinter. Das war übrigens das zweite mal in diesem Thread.

Das hört sich doch schon anders an. Du hast behauptet, Stroustrup hätte nichts derartiges gesagt.

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

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.

Zur Motivation warum ausgerechnet Laufzeit-Polymorphie in der Definition sinnvoll ist, fasse ich mal zusammen. Ein Objekt ist eine konkrete (Speicher-)Ausprägung. Im Fall von Klassen sind Objekte also die Instanzen der Klassen. Daraus ergibt sich bereits die besondere Bedeutung einer Polymorphie, die zur Laufzeit stattfinden muss. Denn eine solche Polymorphie hat zwingend das Objekt, also die konkrete Ausprägung, zum Mittelpunkt an dem sie sich orientiert. Bei explizit typisierten Sprachen also eben nicht den Typ der Variabel, über die man das Objekt zufällig anspricht, sondern wirklich den Typ des Objekts selbst. Ein Motorrad verhält sich also zum Beispiel auch wie ein Motorrad auch wenn und obwohl ich es als Fahrzeug anspreche. Bei Polymorphie-Formen, die nicht zur Laufzeit stattfinden müssen, benötigt man dagegen keine konkrete Ausprägung, also auch kein Objekt, und kann sich daher auch nicht am Objekt orientieren. Die besondere Bedeutung einer Polymorphie, die zur Laufzeit stattfindet, ergibt sich für Objekt-Orientierung also bereits von alleine aus der Definition von Objekt.
Laufzeit-Polymorphie ist demnach im Gegensatz zu anderen Techniken ganz klar objekt-orieniert. Und das ist die Motivation es zu einem Definitionskriterium für Objekt-Orientierung zu machen.

Bei

struct A {
  void a();
};

A a;
a.a();

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.

Das Problem mit der Unterscheidung zwischen Laufzeit/Statischer-Polymorphie ist einfach der, das man sich von der Implementierung abhängig macht. OOP ist aber nichts was vom Compiler entschieden wird, sondern eine Denk- und Implementierweise (ansonsten ist der Begriff OOP einfach nicht nützlich für den größten Teil der Programmierer!)

struct A {
  virtual void foo();
};
struct B : public A {
  virtual void foo();
};
B b;
b.foo();

Hier passt es vielleicht auch ganz gut noch schnell auf die Argumente bezüglich des hypothetischen Gedankenspiels "statische Polymorphie zur Laufzeit zu erledigen" einzugehen. Man kann selbstverständlich auch ohne Zwang Dinge in die Laufzeit verlegen. Wenn dies aber nicht notwendig ist, würde man - auch wenn die ersten beiden Definitionskriterien erfüllt sind - trotzdem nicht von einer objekt-orientierten Sprache sprechen. Denn die Objekt-Orientierung folgt dann auch nicht aus der Sprache selbst, sondern aus der Technik, die sich entschieden hat, Nicht-Objekt-Orientiertes objekt-orientiert zu implementieren. Erst wenn die Sprache die oben beschriebene Objekt-Orientierung erzwingt (oder erzwingen kann - man muss OO ja nicht immer nutzen), kann auch die Sprache selbst sinnvoll als objekt-orientiert bezeichnet werden.

Ich verstehe nicht, wie du das Argument entkräften willst.

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.

Ansonsten wäre es ja durchaus möglich auch laufzeit-Polymorphie statisch zu erledigen.

Xin schrieb:
Meine Definition von Objekt ist alles außer void.
Meine Definition von Objekttyp ist der Datentyp des Objektes.
int a;
ist ein Objekt, der Objekttyp ist int.
Ja, das hört sich sehr nach Stroustrup an.

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...

Xin schrieb:

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

oder vielleicht eher solche Comments?

Es ist schon spät, oder? Wenn's für Dich zu spät wird, dann geh besser schlafen. Derartige Äußerungen sind unpraktisch, wenn man anderen unterstellt Unfug zu schreiben.

Deine geballte Kompetenz ist ein Plagiat und damit ein Griff ins Klo. Wenn das alles war, war das als Argument wirklich beeindruckend. Deine geballte Kompetenz reichte leider nicht, um korrekt abzuschreiben, denn Du hast leider die Zusatzbedingung vergessen, dass sichergestellt sein muss, dass von der Klasse keine Ableitung existiert. Damit hat sich Deine geballte Kompetenz leider als doppelter Griff ins Klo erwiesen.
Herzlichen Glückwunsch.

Wenn man nun das Denken eingestellt hat und merkt, dass man zwischen Klassenorientiert und Objektorientiert nicht mehr unterscheiden kann, dann kann man entweder das Denken wieder anwerfen [...]

Ich liege richtig, unabhängig davon, was in Wikipedia steht, unabhängig davon, wieviele Leute das in diesem Forum anders sehen. Das hat auch nichts mit Sturheit zu tun, sondern eben mit der Tatsache, dass ich von Deinem Point of View mich in den letzten Jahren durch die Entwicklung meines Compilers und das Lesen von entsprechender Fachliteratur auf meinen Point of View bewegt habe.

etc.

valaBoo

Hui, was für eine Beschreibung, ist sicher hilfreich.

Wenn jemand will, kann er auch diesen: http://www.xhodon.de/?user_id=14 Link anklicken, damit tut ihr mir einen großen Gefallen, und lernt evtll. noch ein super Browsergame kennen.
(Nur so nebenbei, also wer drauf klicken will dann klickne )

MfG
valaBoo

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.