Performancemythen?

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.

Undertaker

Wie die Krähen schrieb:

Man stelle sich einfach mal ein Treffen zwischen den opponenten vor, die dann sachlich ihre argumente vortragen...

...dann wär' schnell klar, dass für die einen objektorientierung eine abstraktionstechnik bzw. denkweise ist (man vereinfacht gewisse dinge, um sie zu zerlegen, weil diese stückchen handlicher sind als ein komplexes system) während die anderen auf konkreten umsetzungen für computer herumreiten.
witzigerweise versuchen anhänger der 'philosophischen' sichtweise diese mit source-codes zu belegen, was natürlich die 'computerfreaks' niemals gelten lassen können.

minhen

Undertaker schrieb:

...dann wär' schnell klar, dass für die einen objektorientierung eine abstraktionstechnik bzw. denkweise ist (man vereinfacht gewisse dinge, um sie zu zerlegen, weil diese stückchen handlicher sind als ein komplexes system) während die anderen auf konkreten umsetzungen für computer herumreiten.

Das macht Marcus in seinem Buch ganz brauchbar indem er von "Kandidaten für Objekte" (das sind in der schwammigen Definition bereits Objekte) und von "Objekten" (gemaß der präzisen Definition) spricht. Bei der Abstraktionstechnik, die du ansprichst, denkt und plant man übrigens auch in Instanzen von Klassen, mithin mit Objekten. Denn auch wenn es die "Gegner" hier offensichtlich auf keinem Auge verstehen, ist die präzise Definition von Objekt-Orientierung eben sehr wohl interpreter- und compilerunabhängig. Aber das wurde bereits gesagt. Das ist aber zum Beispiel auch die Grundlage, warum man überhaupt von z.B. objekt-orientiertem Design sprechen kann.

Shade Of Mine

Xin schrieb:

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.

Das lustige dabei ist aber: wenn der Compiler zur Laufzeit kompiliert - kennt er definitiv alle Typen die es gibt und kann daher _immer_ optimieren und wenn ein neuer Typ dynamisch dazu kommt (dynamisch neu geladen) dann kompiliert er eben neu.

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

Das ist nun echt kein Problem compiler zu schreiben die sowas optimieren. Das darf nicht die Definition von OOP ändern wenn es modernere Compiler gibt die intelligenter optimieren.

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

Fakt ist: es kommt vor und ist damit kein OOP mehr, oder?

In JS ist überhaupt nichts statisch. Wenn Du das Interface garantieren kannst und damit Objekte austauschbar machen kannst, arbeitest Du objektorientiert.

Und warum ist der Template Code:

class Trianlge { public: void draw(){} };
class Circle { public: void draw(){} };
template<typename Shape>
void foo(Shape& s) {
  s.draw();
}

dann nicht OO? (btw, ursprünglich war mein JS Code - der von dem Shape Beispiel nicht OO bei dir. Ich bringe immer das selbe Beispiel, deshalb mag ich nicht dauernd den Code schreiben, aber hier:

function Lampe(energiequelle) {
  var e=energiequelle;
}
function Dynamo() {
  this.get_energie=function() {}
}
function Atomreaktor() {
  this.get_energie=function() {}
}

Dieser Code war ursprünglich bei dir nicht OO - ist er es jetzt?

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.

Weil das ein komplett anderes Thema ist. Deshalb mag ich nicht darüber diskutieren weil das vom aktuellen Thema ablenkt.

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 wohl. Und was der Compiler optimiert ist egal - solange der Code dann noch richtig läuft. Er kann zB 2 Klassen anlegen: eine die das Interface implementiert und eine die das nicht tut.

Aber der Punkt ist: ich kann Templates natürlich zur Laufzeit nachladen - ich brauche lediglich eine VM dazu. In C# ist das gang und gebe.

Interpreter, Java und .NET haben das Problem, dass sie selten statisch ablaufen. ^^

Interessanter Punkt, nicht wahr? Aber Fakt ist: es gibt Interpreter und VMs. Scheitert eine Definition nun an dem vorhandensein solche Techniken - ist die Definition fragwürdig.

Erlaubt C++/CLI überhaupt die übersetzung, ohne ungefragt 'virtual' hinzuzufügen?

Wo denn?

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!?

Ja: wenn ich zur Laufzeit kompiliere - kompiliere ich ja mehrmals und modifiziere so den Code zur Laufzeit. Also nicht ich, sondern die VM.

Eine Funktion in Java wird zB erstmal kompiliert und dann wenn man merkt dass sie performance kritisch ist, wird sie mit stärkeren optimierungen kompiliert. Selbes kann man Problemlos auf ein Objekt System anwenden. Dann ändert sich der generierte Code zur Laufzeit extrem. Weil zB virtuelle Aufrufe komplett "statisch" aufgelöst werden. Statisch im Sinne von: Bei der Kompilierung.

Du kompilierst also JavaScripts mit Java...?

Warum nicht? Was spricht dagegen?

Man kann also annehmen, dass nach Alan Kay weder C++ noch Java objekt-orientiert sind. Ist das eine brauchbare Definition?

Die Frage ist: wir wollen OOP nicht genau definieren und bringen deshalb Beispiele die diese und jene Definition widerlegen. Gibt es denn eine entgültige Definition.

Scheinbar haben eine Menge Leute eine Menge zu OOP gesagt und vieles widerspricht sich komplett. Das ist der Punkt: ist OOP so leicht definierbar.

Xin und du haben zB eine unterschiedliche Auffassung in vielen Punkten und das obwohl ihr eigentlich die selbe Definition gut findet. Nicht wahr?

rüdiger

minhen schrieb:

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.

Nach meiner Ansicht findet eine Orientierung am Objekt statt, nur eben zu eine Zeitpunkt, an dem das Objekt noch nicht zwangsläufig existiert. Aber wie ich schon sagt, wir sind eigentlich an dem Punkt, wo wir uns wohl gegenseitig nicht weiter bringen werden. Ich verstehe deinen Standpunkt und finde das er in sich geschlossen ist und kann ihn akzeptieren.

minhen schrieb:

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.

Dir steht es frei dich von der Abwesenheit von encapsulation in CLOS zu überzeugen.

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.

Ich finde sie nicht wesentlich schwammiger, als die Definition von Stroustrup. Und sie erfasst nach meiner Meinung mehr Systeme, die als OO angesehen werden, als Stroustrups Definition (die nach meiner Meinung zum Beispiel CLOS ausschließt). Außerdem schließt sie den statischen-Polymorphismus nicht aus.

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.

Kann sie zu speziell sein? Aus deiner Sicht ja. Aus meiner Sicht ist deine Definition auch zu speziell, da sie nach Möglichkeit Systeme ausschließt. Sicher geht Kay nicht den Weg die (bekannten) OO-Systeme anzuschauen und dann daraus eine Definition abzuleiten. Aber das ist ja auch nicht verwunderlich, da seine Definition schon vor diesen OO-Systemen existierte und er so direkt zu den OO-Systemen hingeht und sagt "Entspricht es meiner Definition oder tut es das nicht".

Undertaker

minhen schrieb:

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.

nee, dir ist das nicht klar. 'meine' definition ist noch viel schwammiger. ja ich weiss, richtige definitionen dürfen nicht schwammig sein, was mir aber ziemlich egal ist. mich stört an der nachrichten-austausch-definition der begriff 'nachricht', dessen definition ist mir leider nicht schwammig genug.

minhen schrieb:

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.

ja, diese definition ist ziemlich präzise, aber ob sie durchdacht ist, will ich mal anzweifeln. auf jeden fall ist sie viel strenger als 'nachrichten verschicken', aber deswegen nicht 'praktisch und brauchbar' sondern eher 'praktisch unbrauchbar'.