Performancemythen?

DEvent

scrub schrieb:

Xin schrieb:

Die freundlichen Kommentare oder dass ich das heute schon hier sagte, wird man bis dahin vergessen haben und mich weiterhin als den komischen Kerl ansehen, der sich aus unerfindlichen Gründen nicht an die Massen anpasst. Mein Verständnis hilft mir allerdings im Job, was sich in guten Zeugnissen wiederfindet, was wichtiger ist, als dass man mich im C++-Forum respektiert.

Manchmal hat die Masse Recht, manchmal haben sogar alle Recht. Wenn Du 2 + 2 = 11 behauptest und ich 2 + 2 = 4, können wir beide Recht haben.
Nur, weil Du eine anscheinend isolierte Meinung vertrittst, hast Du noch lange nicht Recht.

Xin schrieb:

Seit x Seiten warte ich auf eine Erklärung, wie die "übliche" Definition von "OOP" begründet, dass ein Algorithmus, der sich nicht am Objekt orientiert, "objektorientiert" genannt wird.

Ganz einfach, es ist völlig wurscht, ob sich irgendwas an Objekten orientiert- der Ansatzpunkt für die "übliche" Definition ist viel einfach: Es gibt Objekte und sie werden verwendet. Das reicht bereits- kein virtual, kein sontnochwas. Keine Algorithmen, die sich an irgendwas orientieren- ich als Programmierer denke in Objekten.
Für einen genialen Kopf wie Dich zu einfach?

hmm also wenn der Programmierer an OOP gedacht hatte, waehrend er ein Algorithmus geschriebene hat, dann ist dieser automatisch OOP. Cool.

Phoemuex schrieb:

Die Definition, die du für OOP benutzt, ist nicht die gängige. Du nimmst einen Teil dessen, was allgemein als OOP verstanden wird (virtuelle Methoden, bzw. Polymorphie, virtuelle Methoden sind ja praktisch nur ein Implementierungsdeteil, um Polymorphie zu erreichen) und definierst das als das einzig und allein von OOP bezeichnete. Das ist aber im üblichen Sprachgebrauch nicht so. Dort ist es nämlich so, dass der Begriff OOP sehr viele verschiedene Dinge wie Kapselung, Polymorphie, Typsicherheit und vor allem die Zusammenlegung von Daten und Funktionen zu einem Datentyp bezeichnet. D.h. es existieren nicht getrennt Daten und Funktionen, sondern man schreibt eine Klasse, die sowohl die Daten als auch die Methoden, d.h. die Funktionalität der Objekte der Klasse bestimmt.

Wieso vor allem die die Zusammenlegung von Daten und Funktionen zu einem Datentyp? An dieser Zusammenlegung ist nun wirklich nichts besonderes. Genauso wie an der Typsicherheit und der Kapselung. Es geht auch ohne, es geht auch mit. Gibt dazu genuegend Sprachen.

otze schrieb:

falsch. Wenn du vererbung verwendest, musst du jede Klasse verändern, wenn du Rakete hinzufügst. das ist double dispatching, und die OOP bietet dafür keine Lösung. Ausser natürlich, für die 3 Objekte reicht derselbe CollideWith algorithmus. Aber wenn man annimmt, dass Asteroid ein kreis, raumschiff ein quadrat und rocket ein Strich ist, dann brauchst du für jede kombination eine eigene methode. Und anstatt dann an einer Stelle einfach die neuen funktionen hinzuzufügen, musste es dann in jeder Klasse machen. dazu kommt, dass du dich ab dann noch damit rumschlagen kannst, dass in Raumschiff Rakete noch nicht definiert ist und du dann nochmal irgendwo ne vorwärtsdeklaration brauchst(in C++ natürlich). Ohja, nicht zu vergessen, dass du dann noch das Problem hast, dass jede Klasse erstmal rauskriegen muss, welchen genauen typ nun das übergebene objekt hat, damit dann die endgültige methode aufgerufen werden kann.

Ich wuerde einfach den Kreis, das Quadrat und den Strich abstrahieren und ein Interface fuer vergleiche anbieten lassen.

In Java funktioniert es doch auch, da implementiert man einfach das Comparable-Interface und schon kann jeder beliebiger Algorithmus meine Objekte sortieren, egal ob es Kreise, Quadrate oder Striche sind.

otze

Xin schrieb:

Schön, ob Du es jetzt ausschreibst oder einen Teil davon durch ein Template erzeugen läßt, Du darfst es nicht vergessen, sonst bäng!
Templates helfen nicht dabei, Dinge nicht zu vergessen.

nein, aber es ist ein unterschied, ob ich einmal oder 10x vergessen kann. Vorallem wenn es bei 10x nicht auffällt.

Posting lesen, ich habe extra drauf hingewiesen, dass ich diesbezüglich erweitert habe, damit man nicht selbst denken muss und auch die Frage nach kommutativen Operatoren ist geklärt.
Nochmal zum mitmeißeln: Es muss nicht jede Klasse erweitert werden.

doch, es muss. wenn a.foo(b) ein anderes ergebnis liefert oder eine berechnung braucht als b.foo(a) dann muss jede Klasse erweitert werden. Und selbst wenns nicht alle sind, dann wird es nur noch komplizierter: welche methoden muss ich denn dann immer hinzufügen oder umbauen? Ist es nun ein fehler wenn eine bestimmte methode in einer Klasse fehlt oder nicht?

otze schrieb:

Wenn ich den multidispatcher nicht erweiter, dann krieg ich sofort ne exception um die Ohren geworfen, weil er diesen neuen Typ nicht kennt.

Super. Den Anwender wird's freuen.
Eine pure virtual Function lässt den Compiler meckern.

ja, wenn es eine gibt. aber schau dir das mal an, denn das passiert bei der Lösung über die wir bisher geredet haben:

class Bar;
class Foo: public Object
{
    public:
        bool collide(const Object* o)const
        {
              if(typeid(o)==typeid(Bar)
              {
                  //collison mit Bar berechnen
              }
              throw UnknownType();
        }
};

bool test_collision(const Object* o1,const Object* o2)
{
    return o1->collide(o2);
}

class FuBa:public Object{...};

int main()
{
    Object* test1=new Foo;
    Object* test2=new FuBa;
    test_collision(test1,test2);//hier soll der compiler meckern? ich glaube nicht, xin!
}

oder willst du jetzt sogar für jede neue Klasse das Interface ändern?

class Object
{
    public:
       virtual bool collide(const Rocket*)=0;
       virtual bool collide(const Asteroid*)=0;
       virtual bool collide(const Starship*)=0;
};

++Klassen_zum_ändern;
Wobei ich mich natürlich frage wie du das zusammen mit: "Es muss nicht jede Klasse erweitert werden" laufen soll.

otze schrieb:

Der grund, weshalb multimethoden wahrscheinlich nicht in den Standardkommen ist desweiteren nicht, das virtual mächtiger ist

Ich sagte nicht, dass es mächtiger ist, ich sagte, dass sie dem Compiler die Möglichkeit geben, zu meckern.

nein, hast du nicht!

siehe hier.

Ich sehe nicht, dass sie mächtiger wären als virtuelle Funktionen - das wird das C++ Kommitee davon abhalten, sie in C++ aufzunehmen.

Jester

DEvent schrieb:

hmm also wenn der Programmierer an OOP gedacht hatte, waehrend er ein Algorithmus geschriebene hat, dann ist dieser automatisch OOP. Cool.

Ja, war doch garnicht so schwierig. Wobei es natürlich nicht um Algorithmen ging, und der Benutzer nicht an OOP denkt, sondern in Objekten (sie also als primäres Strukturierungsmittel einsetzt). Natürlich denkt man auch nicht nur daran, sondern verwendet sie tatsächlich so, so dass sich diese Denkweise auch im resultierenden Code niederschlägt.

@Xin: Dir muß doch aber schon klar sein, dass zwischen einem Faktor > 1 (tatsächlich wohl 1.02) und der Angabe 5-10 wirklich Welten liegen. Du mußt auch mal an das denken was mit solchen Threads passiert... ein Anfänger liest es. Der liest boah, C ist 5-10 mal so schnell wie C++. Unter heutzutage schneller versteht man dann sowas wie naja, so Faktor 3-5. Das was dadurch entsteht sind: Performancemythen. Zumal ja inzwischen klar ist, dass schon in 2000 Äpfel mit Birnen verglichen wurden.

Ich hatte es so verstanden, dass hier Performance-Mythen ausgemerzt werden sollen. Oder sollen wir hier lieber welche erzählen? -- Ist sicher auch nett.

Xin

otze schrieb:

Posting lesen, ich habe extra drauf hingewiesen, dass ich diesbezüglich erweitert habe, damit man nicht selbst denken muss und auch die Frage nach kommutativen Operatoren ist geklärt.
Nochmal zum mitmeißeln: Es muss nicht jede Klasse erweitert werden.

doch, es muss. wenn a.foo(b) ein anderes ergebnis liefert oder eine berechnung braucht als b.foo(a) dann muss jede Klasse erweitert werden.

Würdest Du bitte das Posting lesen. Ich bin aus dem Alter raus, um im Niveau "Das ist mein Sandschäufelchen" zu diskutieren, meine Güte...

otze schrieb:

otze schrieb:

Wenn ich den multidispatcher nicht erweiter, dann krieg ich sofort ne exception um die Ohren geworfen, weil er diesen neuen Typ nicht kennt.

Super. Den Anwender wird's freuen.
Eine pure virtual Function lässt den Compiler meckern.

ja, wenn es eine gibt.

Wie, wenn es eine gibt?!
Auf welchem Level willst Du hier diskutieren!?

Wenn ich den Compiler sage, dass er mir daran erinnern soll, eine Variante für jedes Objekt anzulegen, dann gibt es eine pure virtual function. Entweder sag ich's meinem Compiler - und es gibt sie - oder es gibt sie nicht, weil ich zu blöd dafür bin.
Wenn ich zu blöd dafür bin, die Möglichkeiten zu programmieren auch zu nutzen, dann brauche ich mich nicht wundern, wenn's knallt.
Zu blöd zu sein, ist eine Technik, die seit vielen Jahrzehnten erfolgreich von vielen Programmieren angewandt wird - das ist nichts Neues, was uns in dieser Diskussion weiterbringt.

otze schrieb:

aber schau dir das mal an, denn das passiert bei der Lösung über die wir bisher geredet haben:
[...Sourcecode...]

class Object
{
  vortual bool collide(const Object* o)const = 0;
}

Hast Du collide in Bar nicht definiert, meckert er, weil die Stelle, die Du markiert hast sonst nicht möglich wäre.
Das ganze wird nicht kompiliert, weil der Programmierer zu blöd war und es jetzt korrigieren kann. Bei einer Multimethode läuft's bis die Exception kommt. Kommt die beim Kunden, ruft der Kunde beim Chef vom Programmierer an und das ist dann nicht nur blöd vom Programmierer, das ist auch noch blöd für den Programmierer.
Als Programmierer bevorzuge ich virtual. Ich bevorzuge meine Blödheit zu korrigieren, bevor ich sie öffentlich mache.

Ansonsten weise ich vorsichtig auf die Verwendung von Referenzen hin, wobei ich die Nutzung von const in einem Beispielcode schon löblich finde.

otze schrieb:

oder willst du jetzt sogar für jede neue Klasse das Interface ändern?

class Object
{
    public:
       virtual bool collide(const Rocket*)=0;
       virtual bool collide(const Asteroid*)=0;
       virtual bool collide(const Starship*)=0;
};

Du hast absolut keine Vorstellung, was OOP ist, richtig?
Vielliecht eine vage Vermutung, aber selbst mit dem Standard-Unsinn, kann ich mir die Frage hier nicht mehr erklären.

Komm, Du darfst das Schäufelchen haben...

otze schrieb:

otze schrieb:

Der grund, weshalb multimethoden wahrscheinlich nicht in den Standardkommen ist desweiteren nicht, das virtual mächtiger ist

Ich sagte nicht, dass es mächtiger ist, ich sagte, dass sie dem Compiler die Möglichkeit geben, zu meckern.

nein, hast du nicht!

siehe hier.

Ich sehe nicht, dass sie mächtiger wären als virtuelle Funktionen - das wird das C++ Kommitee davon abhalten, sie in C++ aufzunehmen.

Du beschwertest Dich, dass ich Dich nicht ausreichend beachten würde. Nach dem Beweis mangelndem logischen Verständnisses, solltest Du dankbar sein, überhaupt beachtet worden zu sein. Fehlt ja nur noch, dass Du in Großbuchstaben schreibst... <kopfschüttel>

!(v > m) und !(m > v) ist kein logischer Widerspruch. Es ist sogar eine logische Aussage: v = m.

Und ich fügte ja extra noch in meinem Posting an, dass Multimethoden OOP sind, damit keiner auf die Idee kommt, derartig unsinnige Schlussfolgerungen zu ziehen.

Warum das bei Dir jetzt nicht klappte, wäre eine gute Möglichkeit Schlussfolgern zu üben.
Ich hoffe, das war jetzt nicht arrogant.

Unpassend zum aktuellen Verlauf der Diskussion: Ich hatte auf Seite 11 eine Frage gestellt, die meine Definition von OOP zum Kippen bringen könnte. Hat die jetzt schon jemand beantwortet und wenn ja wer und wo. Ich habe bisher noch nix gesehen, wäre aber interessiert.

DEvent

interface Collide
{
    boolean isCollide(Object b);
}

abstract class FliegendesObjekt implements Collide
{
    public boolean isCollide(Object b)
    {
        return this.collideUnknow(b);
    }

    protected boolean collideUnknow(Object unknow)
    {
        return unknow.isCollide(this);
    }
}

// Raumschiff ist ein Quader.
class Raumschiff extends FliegendesObjekt
{
    public boolean isCollide(Object b)
    {
        if ( b instanceof Raumschiff )
        {
            Raumschiff right = (Raumschiff)b;
            // vergleiche this mit right
        }
        else if ( b instanceof Rocket )
        {
            Rocket right = (Rocket)b;
            // vergleiche this mit right
        }
        else return super.isCollide(b);
    }
}

// Rocket ist ein Strich.
class Rocket extends FliegendesObjekt
{
    public boolean isCollide(Object b)
    {
        if ( b instanceof Rocket )
        {
            Rocket right = (Rocket)b;
            // vergleiche this mit right
        }
        else if ( b instanceof Raumschiff )
        {
            Raumschiff right = (Raumschiff)b;
            // vergleiche this mit right
        }
        else return super.isCollide(b);
    }
}

// in 50 Jahren
abstract class NeuesFliegendesObjekt extends FliegendesObjekt
{
    protected boolean collideUnknow(Object unknow)
    {
        throw new UnsupportedException();
    }
}

// EnterpriseSchiff ist eine Kugel
class EnterpriseSchiff extends NeuesFliegendesObjekt
{
    public boolean isCollide(Object b)
    {
        if ( b instanceof Rocket )
        {
            Rocket right = (Rocket)b;
            // vergleiche this mit right
        }
        else if ( b instanceof Raumschiff )
        {
            Raumschiff right = (Raumschiff)b;
            // vergleiche this mit right
        }
        else if ( b instanceof EnterpriseSchiff )
        {
            EnterpriseSchiff right = (EnterpriseSchiff)b;
            // vergleiche this mit right
        }
        else return super.isCollide(b);
    }
}

Wie waehrs damit? Es haette den Vorteil, dass ich weitere Objekt hinzufuegen kann, ohne den ebstehenden Code aendern zu muessen.

DEvent

Jester schrieb:

DEvent schrieb:

hmm also wenn der Programmierer an OOP gedacht hatte, waehrend er ein Algorithmus geschriebene hat, dann ist dieser automatisch OOP. Cool.

Ja, war doch garnicht so schwierig. Wobei es natürlich nicht um Algorithmen ging, und der Benutzer nicht an OOP denkt, sondern in Objekten (sie also als primäres Strukturierungsmittel einsetzt). Natürlich denkt man auch nicht nur daran, sondern verwendet sie tatsächlich so, so dass sich diese Denkweise auch im resultierenden Code niederschlägt.

Ja wie nun? Dankt man nur daran, oder macht man es auch so?

minhen

otze schrieb:

Nun musst du aber auch anerkennen, dass die Gegenseite ausserhalb dem Verweis auf Standarddefinition einen schlechten Stand hat. Unsere Definition ist die eines Objektes aus dem normalen Sprachgebrauch und das Übertragen dieser Objekte und ihren abhängigkeiten auf die Ebene des Programmcodes ist nunmal nicht formal eindeutig definierbar. Das fängt schon damit an, dass der Begriff "Objekt" im allgemeinen Sprachgebrauch nicht eindeutig definiert ist:

Ja, eure Definition basiert auf einem undefiniertem Begriff. Aber das ist schlecht. Sehr schlecht sogar. Denn von einem wissenschaftstheoretischen Standpunkt aus ist sie damit völlig unwissenschaftlich und völlig nutzlos, da völlig beliebig und völlig willkürlich. Du bezeichnest deine Argumentation als wissenschaftlich. Doch legt man wissenschaftliche Standards an ist eure Defintion wie auch manche Argumentation hier die reinste Katastrophe, der wissenschaftliche Worst-Case, pseudowissenschaftliches Vorgehen wie es leibt und lebt. "Schwammig" war lediglich die höfliche Floskel ohne Wissenschaftstheorie explizit in den Mund zu nehmen.
Der Aufschrei ist jetzt natürlich obligatorisch, deswegen sag ich es gleich vorweg: die Begründung findet sich in meinem vorigen Beitrag. Was ich dort anführe ist nichts anderes als Wissenschaftstheorie.

Eine wissenschaftliche Argumentation wäre entweder den Kern Xins Definition direkt anzugreifen oder alternativ eine eigene, wohldefinierte, wissenschaftliche Definition anzubieten. Ersteres unterbleibt, da, wie du selbst sagst, Xins Definition Teil deines eigenen Verständnisses von OOP ist. Zweiteres dagegen unterbleibt, da du mit schwammigen Begriffen und Konzepten arbeitest.

Solange er aber auf diese Fälle nicht eingeht, zb warum statische Polymorphie kein OOP ist, können wir auch nicht weiter argumentieren.

Ich zitiere mal:

Xin schrieb:

Shade Of Mine schrieb:

Wenn du sagst OOP ist eine Technik die mit anderen Techniken verknüpft werden kann - was genau ist dann OOP? Datahiding kein Bestandteil der OOP? Polymorphie aber schon? Schwer zu trennen das ganze.

Eigentlich nicht. Das Überschreiben von virtuellen Funktionen ist erforderlich, sonst könnte man nicht objektabhängig unterschiedliche Funktionen rufen. Objektorientierte Abläufe sind ist ja genau der Hintergrund, weshalb man virtuelle Funktionen überschreibt.
Das Überschreiben von statischen Funktionen oder das Überladen beliebiger Methoden ist dafür nicht erforderlich.

Xin schrieb:

Shade Of Mine schrieb:

In C++ und Java sieht man eben nur einen kleinen Teil der OOP. Wobei du halt auch dort Teile der OOP die sich nicht miteinander schneiden ignorierst. zB statische Polymorphie - aber wo trennt man da?

Überladene Funktionen sind Funktionen gleichen Namens aber unterschiedlicher Signatur. Sie sind damit vom Compiler problemlos zu unterscheiden. Statische Funktionen sind grundsätzlich nicht objektorientiert, sie sind eben statisch. Und sie bleiben statisch, wenn sie in einem anderen Namespace liegen. Ich sehe da eine ganz klare Grenze, die absolut keine Frage läßt: nicht OOP.

Das sind, bedenkt man Xins Verständnis eines Objekts und der Orientierung (was er beides bereits mehrmals wiederholt hat), schlüssige und einwandfreie Antworten, weshalb statische Polymorphie keine OOP ausmacht.
Es fragt sich also wer hier wessen Aussagen ignoriert ...

asc schrieb:

minhen schrieb:

Eine Sprache ist also dann objektorientiert, wenn sie die drei Konzepte ... direkt unterstützt. Unterstützung bedeutet, dass entsprechende Hilfsmittel in der Sprache verfügbar sind... Direkt kann nur bedeuten, dass diese Hilfsmittel unmittelbarer Bestandteil der Sprache sein müssen. Folglich macht weder die Möglichkeit Objekt-Orientierung selbst zu bauen noch eine externe, objektorientierte Library eine Sprache objektorientiert.

Die logische Konsequenz ist, dass man keine objekt-orientierte Sprache benötigt um objekt-orientiert zu programmieren.

Also irgendwie wiedersprichst du dir hierbei. Wenn ich deinen ersten Abschnitt betrachte würde mir als logische Konsequenz nur bleiben zu sagen: Um OOP zu betreiben bedarf es einer OO-Sprache.

Nein. OO ist nach Stroustrup die eine, OOP die andere Sache. Mein vorletzter Satz räumt dabei implizit die mögliche Existenz von OOP in Nicht-OO-Sprachen ein. Eine konkrete Existenzaussage wird nicht getroffen, es wird aber sehr wohl die Möglichkeit eingeräumt. Daraus folgt natürlich, dass OOP auch ohne OO-Sprache möglich ist.

Jester schrieb:

minhen schrieb:

Darüber hinaus hat Xin sogar erklärt weshalb er "Standard-Referenzen" nicht einfach so akzeptiert - und zwar mit Grundregeln der Logik.

Das ist schlicht nicht wahr. Aber das kann ja jeder selbst nachlesen.

Mir lügen zu untestellen, nur weil du die entsprechende Aussage von Xin ignorierst, vergessen oder nicht verstanden hast, ist nicht nur ausgesprochen arrogant sondern auch dreist.

Aber ich will ja nicht so sein:

Xin schrieb:

Mir bedeutet Logik etwas. Daran halte ich mich. Solange Du nicht mehr zu bieten hast als "Ich stimme nicht zu" und in Deinen Quellen nicht das "Warum" zitieren kannst, bedeutet mir Dein Wort genausowenig wie die Links.

Um das zu verstehen muss man natürlich Logik und Argumentation kennen. Wenn man Xin also etwas vorwerfen kann, dann, dass er "zuviel" Wissen voraussetzt. Zum Thema Logik und Argumentation:
Die Wahrheit einer Aussage ist davon logisch unabhängig wer sie tätigt.
Die Wahrheit einer Aussage ist davon logisch unabhängig wieviele sie für wahr oder falsch halten.
Das sind Grundregeln der Logik in der Argumentation und auf diese beruft sich Xin hier ziemlich eindeutig.

otze

Xin, du zeigst grad herrliche sturheit, und eine enorme fähigkeit das problem zu verkennen. Ich werde deine beleidigungen ignorieren, und einfach weitermachen.

Würdest Du bitte das Posting lesen. Ich bin aus dem Alter raus, um im Niveau "Das ist mein Sandschäufelchen" zu diskutieren, meine Güte...

Ja, ich habs gelesen. Ich weis nicht, was es mit Sandschäufelchen zu tun hat, aber ok. Fakt ist, du brauchst im zweifel 2 algorithmen. Wenn du sie nun in 1 funktion propfst ist das zwar sehr zweifelhaft, aber irgendwie kann man das sicher zurechtbiegen. Wichtig ist aber in dem Zusammenhang, dass für einen leser des codes nicht ersichtlich ist, ob ein bestimmter algo nun in collide fehlt, weil er vergessen wurde, oder ob er fehlt weil er in einer anderen Klasse drin steckt. Er muss also in jedem Fall beide Klassen anschauen um diese Frage zu beantworten. bei multimethoden steht das alles direkt untereinander in einer einzelnen Datei.

class Object
{
  vortual bool collide(const Object* o)const = 0;
}
Hast Du collide in Bar nicht definiert, meckert er, weil die Stelle, die Du markiert hast sonst nicht möglich wäre.

Darum geht es aber nicht. Wenns collide nicht gibt knallts, das ist klar.
Aber du musst dran denken, dass du Collide erweitern musst, darum und um nichts anderes, und kein pure virtual wird dich davor retten. Auch der Compiler wird dir nicht sagen, dass ein if zweig fehlt für den fall, dass du Rocket neu deklariert hast und Asteroid::collide noch keinen test für rocket besitzt(oder Rocket kein Test für Asteroide, oder irgendeine der beiden Klassen ein collide für beide Fälle). Für genau diesen Fall brauchst auch du eine exception. Dein Nachteil ist, dass du nicht sicher sein kannst, wann die exception geworfen wird, denn dieser Fall dass Asteroide und Rocket kollidieren muss erstmal auftreten. bei multimethods kann diese exception aber garnicht auftreten.
Schau dir nochmal den von mir geschriebenen Code an, und du wirst das Problem selbst erkennen.

Ansonsten weise ich vorsichtig auf die Verwendung von Referenzen hin, wobei ich die Nutzung von const in einem Beispielcode schon löblich finde.

nö, muss ich nicht. referenzen sind in einer polymorphen umgebung meistens hinderlich und für container brauchst du eh pointer. Mal davon ab brauchst du mir wohl nicht zu erklären, wie man C++ programmiert, danke.

otze schrieb:
oder willst du jetzt sogar für jede neue Klasse das Interface ändern?
class Object
{
    public:
       virtual bool collide(const Rocket*)=0;
       virtual bool collide(const Asteroid*)=0;
       virtual bool collide(const Starship*)=0;
};
Du hast absolut keine Vorstellung, was OOP ist, richtig?
Vielliecht eine vage Vermutung, aber selbst mit dem Standard-Unsinn, kann ich mir die Frage hier nicht mehr erklären.

Komm, Du darfst das Schäufelchen haben...

http://de.wikipedia.org/wiki/Sarkasmus

Dass du mir btw sone Designkatastrophe zutraust, spricht Bände

@DEvent

Wie waehrs damit? Es haette den Vorteil, dass ich weitere Objekt hinzufuegen kann, ohne den ebstehenden Code aendern zu muessen.

wir haben darüber shcon gesprochen, oder das ist ATM Xins position. Aber deine Implementation hat den Nachteil, dass sie bei nicht kommutativen funktionen nicht funktioniert. dafür brauchst du dann einen weiteren parameter der angibt, welches Objekt nun das aufrufende ist, und musst daran dann wieder unterscheiden. Auf diese Weise funktioniert es dann, aber ist fehleranfällig. Was ist, wenn ein Programmierer eine kollision vergisst oder ein vorhandenes Objekt das kollidieren kann nicht kennt und diese kollision dann auftritt?
In dem Fall kommts bei dir zu einer endlosschleife, weil er andauernd die Parameter versucht zu tauschen um eine passende funktion zu finden(mit parameter kannste das testen, aber dann musst du eine exception werfen, und eben die will Xin ja nicht haben).

Bei multimethods, zumindest wie sie in C++ implementiert werden können, gibts zur compilezeit den Fehler.

Jester

minhen schrieb:

Mir lügen zu untestellen, nur weil du die entsprechende Aussage von Xin ignorierst, vergessen oder nicht verstanden hast, ist nicht nur ausgesprochen arrogant sondern auch dreist.

Offensichtlich scheinst Du das was er betreibt ja für Logik zu halten und die Schlüsse auch für logisch zu halten. Das macht ja auch nix. Schließlich ist deren Wahrheitsgehalt ja nicht davon abhängig ob Du sie für wahr/gültig hältst oder nicht. Es ist also ziemlich dreist und arrogant und so von Dir mir zu unterstellen ich würde lügen, wenn ich sage dass das nicht stimmt... oder so ähnlich.

Um das zu verstehen muss man natürlich Logik und Argumentation kennen.

Ja, das sind zufällig zwei Dinge mit denen ich mich recht gut auskenne.
Ich halte das was er vorträgt nicht für schlüssig und insbesondere bin ich der Meinung, dass seine Definition nicht das abdeckt, was OOP ausmacht. Es deckt eben nur einen Teil davon ab und ist damit als Definition ungenügend. Vom wissenschaftstheoretischen Standpunkt vielleicht nicht katastrophal, aber halt unnütz. Mein OOP-Methodenbaukasten enthält mehr als virtual (nämlich vor allem Objekte als zentrales Abstraktionsmittel und entsprechende Kompositionstechniken), aber das habe ich ja schon mehrfach erklärt. Eine OOP-Definition, die diese Dinge nicht mit abdeckt greift zu kurz.

Dadurch, dass ich einen recht umfangreichen Teil meines Studiums auch mit Mathematik verbracht habe, denke ich auch ganz gut einschätzen zu können, wann eine Definition etwas taugt, sowie was schwammig ist und was nicht.

So, nun kannste mich dann aburteilen.

Xin

minhen schrieb:

Wenn man Xin also etwas vorwerfen kann, dann, dass er "zuviel" Wissen voraussetzt.

Hmm... ich weiß nicht...?! Was muss man denn alles Wissen, um meine Definition zu verstehen?
Eigentlich dachte, ich hätte alles notwendige Wissen oft genug vorgestellt und man müsste das nur lesen.

otze schrieb:

Xin, du zeigst grad herrliche sturheit, und eine enorme fähigkeit das problem zu verkennen. Ich werde deine beleidigungen ignorieren, und einfach weitermachen.

Schade eigentlich.

otze schrieb:

Xin schrieb:

Würdest Du bitte das Posting lesen. Ich bin aus dem Alter raus, um im Niveau "Das ist mein Sandschäufelchen" zu diskutieren, meine Güte...

Ja, ich habs gelesen. Ich weis nicht, was es mit Sandschäufelchen zu tun hat, aber ok. Fakt ist, du brauchst im zweifel 2 algorithmen.

Bei nicht kommutativen Dingen, kann das passieren. Aber keiner zwingt mich, deswegen alte Klassen anzufassen.

otze schrieb:

Wenn du sie nun in 1 funktion propfst ist das zwar sehr zweifelhaft, aber irgendwie kann man das sicher zurechtbiegen. Wichtig ist aber in dem Zusammenhang, dass für einen leser des codes nicht ersichtlich ist, ob ein bestimmter algo nun in collide fehlt, weil er vergessen wurde, oder ob er fehlt weil er in einer anderen Klasse drin steckt. Er muss also in jedem Fall beide Klassen anschauen um diese Frage zu beantworten. bei multimethoden steht das alles direkt untereinander in einer einzelnen Datei.

Das ist ein akzeptables Argument.
Aber es ist überwiegt nicht.

In meinem Fall gibt es genau zwei Möglichkeiten, den Algorithmus unterzubringen. Von "nicht ersichtlich" kann man da noch nicht sprechen. In Deinem Fall gibt es beliebig viele Möglichkeiten, die Multimethoden unterzubringen, von denen eine sinnvoll erscheint. Wenn der Entwickler ausreichend Disziplin hat, gibt's nur eine Möglichkeit den entsprechenden Part einer Multimethode zu finden. Fehlt die Disziplin, dann gute Nacht.
Dafür musst Du bei einer Erweiterung viele Dateien anfassen und dafür sorgen, dass Du nichts vergisst, denn der Compiler meckert nicht, wenn Du's vergißt.

Was Du sagst, ist nicht falsch. Wo man hier mehr Vorteile sieht - 2 Möglichkeiten und nur eine Datei ändern - oder (hoffentlich) nur eine Möglichkeit und viele Dateien anfassen (hoffentlich vergisst man keine) - dann kann ich das als Meinung durchaus akzeptieren.
Ich teile sie nicht.

Aber hier stehen die OO-Möglichkeiten überhaupt nicht zur Diskussion - also warum diskutierst Du mit mir derart unwichtige Details?
Widerlege doch lieber mal meine Vorstellung von OOP, darum geht's doch hier.

otze schrieb:

class Object
{
  vortual bool collide(const Object* o)const = 0;
}
Hast Du collide in Bar nicht definiert, meckert er, weil die Stelle, die Du markiert hast sonst nicht möglich wäre.
Darum geht es aber nicht. Wenns collide nicht gibt knallts, das ist klar.
Aber du musst dran denken, dass du Collide erweitern musst,

Ich schrieb bereits, warum ich die Collide-Versionen von zuvor geschriebenen Objekten nicht erweitern muss, inkl. Berücksichtigung von Kommutativität.

Ansonsten weise ich vorsichtig auf die Verwendung von Referenzen hin, wobei ich die Nutzung von const in einem Beispielcode schon löblich finde./quote]
nö, muss ich nicht. referenzen sind in einer polymorphen umgebung meistens hinderlich und für container brauchst du eh pointer.

Referenzen sind Pointer, die lediglich sichererstellen (das Wort ist korrekt geschrieben), dass der Zeiger valid ist. Ein Vorteil, den man nicht unbedingt verwerfen muss.

otze schrieb:

Dass du btw nicht gemerkt hast, dass ich das niemals hätte ernst meinen können zeugt nicht grade von Respekt gegenüber dem gesprächspartner(wie du mit der Antwort ansich eigentlich sehr schön beweist).

*lach*, der war gut.

Außerdem, was willst Du? Ich nehm Dich mit dem Posting doch auch nicht ernst, warum beschwerst Du Dich also jetzt?
Wenn Du Respekt willst, schreib doch etwas, was man ernstnehmen kann.

Jester schrieb:

Dadurch, dass ich einen recht umfangreichen Teil meines Studiums auch mit Mathematik verbracht habe, denke ich auch ganz gut einschätzen zu können, wann eine Definition etwas taugt, sowie was schwammig ist und was nicht.

*WINK*
Mehrere Befürworter der Standard-Definition haben schon klargestellt, dass (Zitat) *die* (/Zitat) Definition schwammig ist, was wissenschaftlich, wie mathematisch bedeutet: Taugt nix.
Wenn Du als mathematisch geschulter Mensch "schwammig" als mathematisch akzeptabel beschreibst, dann habe ich den Verdacht, dass der recht umfangreiche Anteil Deines Studiums Mathematik dadurch zustande kam, weil Du die Matheschein nie beim erstenmal bekommen hast. Das ist allerdings eine reine Mutmaßung, keine Behauptung.

Entweder die Definition ist schwammig, weil alle sie verstanden haben und davon einige festgestellt haben, dass sie schwammig ist, oder Du hast Deine eigene Definition und die anderen haben eine andere. Dann gibt es aber keine "Standard-Definition", dann reimt sich jeder was eigenes zusammen. Und das ist definitiv auch keine Definition.

Wenn Du Dich zufällig mit Logik ganz gut auskennst - wie Du ja schreibst - dann weißt Du sicher, dass man Schwachpunkte in Definitionen nicht durch Ignorieren beseitigt.

Mr. N

Xin schrieb:

Wenn Du Respekt willst, schreib doch etwas, was man ernstnehmen kann.

Wenn du Respekt willst, lern mal über den Tellerrand zu schauen und vielleicht sogar, was Multimethoden sind.

(Da ich keinen Respekt will kann ich hier wunderbar rummeckern.)

dv_

C++ 5-10mal langsamer als C.
Plattformunabhängiger Assembler.
Nutzt man OOP bei Funktionsrufen, wo keine Entscheidungen zu treffen sind, so verliert man Zeit.

Bitte Xin, werd kein Informatiklehrer/professor. Schreib keine Bücher. Behalt deine "Weisheiten" für dich. Wir haben schon genug IT-Verbrechen wie libxml. Danke.

Simon2

Wird eigentlich irgendjemand hier pro Buchstabe bezahlt ?
Kann es sein, dass irgendjemand "OO (nicht) ist langsamer" als Performancemythos dargestellt hat und anschließend 20 Seiten über die Definition von OO und später über Sprachvorteile gestritten hat (was ein prima Themen für eigene Threads wären).

Mein Vorschlag: Lasst uns doch mal stichwortartig die bisher entdeckten/vermuteten Performancemythen auflisten.

Ich fang' mal an:
- "OO ist (nicht) schlecht für Performance"
- "Die Ordnung eines Algorithmus' ist nicht das einzige Bewertungskriterium für die Performance"
- ...

Was fällt Euch noch auf ?

Gruß,

Simon2.

Shade Of Mine

@DEvent:
call mal bitte basisklasse::mach_was aus der "abgeleiteten" klasse
Das ist keine vererbung, das ist object cloning. du hast dort btw auch keine virtuellen funktionen auf die Xin so steht

Xin schrieb:

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

OK, das ist der Beweis: du kennst nur C++/Java und baust darauf deine kleine OO Welt auf. Macht also keinen Sinn mehr zu diskutieren. Deshalb kleiner Tip an dich: schau dich mal um welche OO Features andere Sprachen haben. Es ist ein wahnsinnig interessantes Thema. OO ohne Klassen zu programmieren - siehe zB JavaScript. Man kann sich zwar Objekte so hinbiegen dass sie ein bisschen wie Klassen wirken, aber man verliert dadurch soviel was JS einem bieten kann.

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Aber man hat keine virtuellen funktionen.

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

Geil. Du weisst nicht was multimethoden sind aber versuchst mitzureden
multimethoden dispatchen zur laufzeit wenn nötig.

Fragen beantwortet, obwohl sie teils "Warum ist es nachts kälter als draußen?" Charakter haben. Hast Du noch mehr Fragen?

es waren die essentiellen fragen ob du dich mit OOP auskennst - du hast versagt. danke.

Die übliche Definition ist also Deiner Aussage nach, dass es nicht genau zu definieren ist. Und damit ist die Mehrzahl dann zufrieden?
Klasse Definition.

Exakt. Weil es eine Denkweise und keine technik ist.

Sprachen neben C++ oder Java machen mir keine bisher Probleme. Mal eben "LISP" einzuwerfen ohne etwas konkretes zu aufzeigen, was meiner Aussage widerspricht, ist dafür etwas wenig.

multimethoden habe ich eingeworfen die kennst du nicht und prototype sprachen kennst du auch scheinbar nicht. also was willst du? alles was du nicht kennst ignorieren?

Zumal Du erstmal Deine Definition an C++ belegen darfst - ich erinnere an die immernoch nicht beantwortete Frage von mir.
Wenn meine Definition auf LISP nicht passen würde, dann wäre das schlecht, aber die "Standard"-Definition passt nichtmals auf C++.

Und genau das ist der Punkt: eine Sprache ist nicht OO sondern ein Programm. C++ unterstützt OO features wie vererbung, polymorphie aber man muss nicht OO programmieren. in der tat sind die meisten C++ programme nicht rein OO.

Der Spaß heißt Reflection. Falsche Baustelle.

Nein, ein sehr relevanter Punkt: wie dynamisch muss Polymorphie sein damit sie polymorphie ist?

Bei wikipedia wird zB überladung bereits zur polymorphie gezählt. ist es nicht interessant dass deine definition nicht die einzig mögliche ist?

zumal du ausser C++ und Java nichts kennst - klar auf C++ und Java trifft deine Definition teilweise zu - aber du hast bereits mehrmals von Forengrößen hier gehört, dass sie OOP als eine Denkweise verstehen. Denk mal darüber nach.

Ich kann dir wirklich nur ans herz legen deinen horizont zu erweitern. Sprachen wie Self und LISP lernen dir ein komplett neues verständnis von OOP. Deshalb verstehst du uns hier auch nicht. Wir sind von dem Klassen denken komplett weg. Und ohne Klassen keine Vererbung und keine virtuellen Funktionen.

Jester

Xin schrieb:

Wenn Du als mathematisch geschulter Mensch "schwammig" als mathematisch akzeptabel beschreibst, dann habe ich den Verdacht, dass der recht umfangreiche Anteil Deines Studiums Mathematik dadurch zustande kam, weil Du die Matheschein nie beim erstenmal bekommen hast. Das ist allerdings eine reine Mutmaßung, keine Behauptung.

War mir fast klar, dass jetzt sowas in der Art kommt. Ich weiß was ich kann. Du bist nicht in der Position das in Frage zu stellen. Dementsprechend ist meine Motivation Dir jetzt irgendwas zu beweisen ziemlich gering. Aber ich kann natürlich meinerseits Vermutungen über Deinen mathematischen Bildungsstand tätigen sowie Deine Erfahrung in logischem Schließen. Über meine Studienleistungen bewahre ich jetzt einfach mal stillschweigen... wäre der Abschluß zu gut, dann bin ich ja völlig unbrauchbar und hab nur auswendig gelernt, ist er zu schlecht bin ich gleich doof. Und notfalls war's halt einfach ne Billiguni. Auf diese Kindereien hab ich einfach keinen Bock.

otze

Ich versuch mal eine weniger schwammige definition aufzustellen(ich hab kein mathematisches Studium und bin kein Diplominformatiker, darum: kreuzigt mich nicht).

Die Objektorientierte Programmierung versucht die Eigenschaften, abhängigkeiten und interaktionsmöglichkeiten von Objekten zu abstrahieren und als programmcode zu modellieren. Die OOP versucht somit, die Denkweise des Menschen direkt als programmcode umzusetzen.

Ein Objekt ist eine Abstraktion eines Physischen oder logischen Gegenstandes. Objekte zeichnen sich dadurch aus, dass sie Zustände und logische Abhängigkeiten untereinander besitzen. Diese Abhängigkeiten können in Form von Vererbung,Komposition oder Interaktion ausgedrückt werden. Der Zustand eines Objektes ist gekapselt und die kontrolle über ihn obliegt allein dem Objekt.

//edit hmm lange nicht komplett. schwer zu definieren. wie bringt man zb rein, dass Funktionen als Objekte augefasst werden können oder dass sogar der Programmcode selbst ein Objekt ist?

Xin schrieb:

Wenn Du als mathematisch geschulter Mensch "schwammig" als mathematisch akzeptabel beschreibst, dann habe ich den Verdacht, dass der recht umfangreiche Anteil Deines Studiums Mathematik dadurch zustande kam, weil Du die Matheschein nie beim erstenmal bekommen hast. Das ist allerdings eine reine Mutmaßung, keine Behauptung.

Dafür bekommst du inf *lol*-Punkte. Echt.

Xin

Shade Of Mine schrieb:

Xin schrieb:

Die Frage 1: Ich programmiere kein Lisp, ich kann dazu keine brauchbare Meinung vertreten. Ich habe mal Google angeworfen, dort wird LISP nachgesagt, dass es wohl OOP kann. Da ich Lisp nicht programmiere und für die Antwort hier auch nicht mal eben schnell lerne, kann ich dazu aber nichts sagen. Ich sehe aber auch nicht, warum grade LISP hier eine große Rolle spielen sollte.

OK, das ist der Beweis: du kennst nur C++/Java und baust darauf deine kleine OO Welt auf.

Es beweist, dass ich kein brauchbare Erfahrung in LISP habe, um damit zu argumentieren.

Shade Of Mine schrieb:

Macht also keinen Sinn mehr zu diskutieren. Deshalb kleiner Tip an dich: schau dich mal um welche OO Features OO ohne Klassen zu programmieren - siehe zB JavaScript. Man kann sich zwar Objekte so hinbiegen dass sie ein bisschen wie Klassen wirken, aber man verliert dadurch soviel was JS einem bieten kann.

Ich habe OO in JS programmiert, um SVG Dokumente zu bearbeiten und habe dafür u.a. grafische Elemente programmiert, wie Buttons, Listenwidgets usw.

Shade Of Mine schrieb:

Frage 2: Kommt auf die Implementierung an, ich sehe kein Problem mit Prototypen oder Klonen von Objekten.

Aber man hat keine virtuellen funktionen.

Wo steht, dass man virtuelle Funktionen oder Klassen für OOP braucht?
Man braucht eine Methode, um OOP umzusetzen und das geht in C++ in der Regel mit virtuelle Methoden.
Man könnte auch z.B. Funktionszeiger verwenden. Es reicht jedenfalls nicht "plain classes" zu nehmen.

Shade Of Mine schrieb:

Frage 3: Überlade in C++ mal z.B. operator +(). Die ist abhängig von zwei Datentypen. Quasi eine Multimethode. Trotzdem ist operator +() keine virtuelle Methode, sondern poplige Überladung.
Lass es mich anders ausdrücken. Virtuelle Funktionen sind besser als Multimethoden aus dem gleichen Grund warum Steine besser als Hosen sind. Beides hat nichts miteinander zu tun.

Geil. Du weisst nicht was multimethoden sind aber versuchst mitzureden
multimethoden dispatchen zur laufzeit wenn nötig.

Ich war in dem Moment bei Überladen in etwa der Form:

bool operator =( BasisObjekt & lhs, BasisObjekt &rhs )

so dass die OO-Möglichkeiten über virtuelle Basisobjekte realisiert würden.
Mea culpa.

Wie ich schon zuvor schrieb: sobald man sich irgendwo einen Irrtum erlaubt, wird es als ultimativer Beweis gewertet. Ich seh's positiv: Ich habe sehr viele Antworten geschrieben, ohne mir Fehler zu erlauben.
Im Verhältnis liege ich damit weiterhin recht gut.

Shade Of Mine schrieb:

Die übliche Definition ist also Deiner Aussage nach, dass es nicht genau zu definieren ist. Und damit ist die Mehrzahl dann zufrieden?
Klasse Definition.

Exakt. Weil es eine Denkweise und keine technik ist.

weil...

Ich lese immer nur Behauptungen und "Du hast nicht recht".

Shade Of Mine schrieb:

Und genau das ist der Punkt: eine Sprache ist nicht OO sondern ein Programm. C++ unterstützt OO features wie vererbung, polymorphie aber man muss nicht OO programmieren. in der tat sind die meisten C++ programme nicht rein OO.

Rein "OO"? Was ist denn reines "OO"?
Ist das sowas wie "Anfänger OO" und "Experten OO", was ich hier schon lesen musste?
Entweder ist es "OO" oder nicht "OO".
Abgesehen davon, dass es bei Dir auch schmutziges OO zu geben scheint, unterscheidest Du wenigstens zwischen OO-Sprache - sie es nicht gibt - und OO-unterstützende Sprachen. Wir sind uns diesbezüglich also einig.

Shade Of Mine schrieb:

Der Spaß heißt Reflection. Falsche Baustelle.

Nein, ein sehr relevanter Punkt: wie dynamisch muss Polymorphie sein damit sie polymorphie ist?

Ich sehe hier keine Relevanz. Begründe, warum Du sie siehst.
Für OO muss ich zur Laufzeit auf überschriebene Funktionen zugreifen können, die objekt orientiert ausgewählt werden. Ich muss die Funktionen aber nicht zur Laufzeit austauschen können. Das ist die Baustelle von Reflection.

Shade Of Mine schrieb:

Bei wikipedia wird zB überladung bereits zur polymorphie gezählt. ist es nicht interessant dass deine definition nicht die einzig mögliche ist?

Überladung gehört zur Polymorphie. Das entspricht meiner Definition.
Überladung ist ein Part der Polymorphie, der nicht für OOP notwendig ist.
Das Überschreiben hingegen ist notwendig. Das könnte ein Grund sein, warum man zwischen Überschreiben und Überladen unterscheidet?

Shade Of Mine schrieb:

zumal du ausser C++ und Java nichts kennst

*smile*
Das lohnt einen Kommentar einfach nicht.

Shade Of Mine schrieb:

Ich kann dir wirklich nur ans herz legen deinen horizont zu erweitern. Sprachen wie Self und LISP lernen dir ein komplett neues verständnis von OOP. Deshalb verstehst du uns hier auch nicht. Wir sind von dem Klassen denken komplett weg. Und ohne Klassen keine Vererbung und keine virtuellen Funktionen.

Vererbung und virtuelle Funktion geht problemlos ohne Klassen, aber nicht ohne Klassifizierung.
C hat keine Klassen und man kann trotzdem OOP verwenden.

Damit Klassifizierung einfacher zu beschreiben ist, hat man in C++ Klassen.

Lies meine Postings, alles schon längst beschrieben.

Jester

Xin schrieb:

Exakt. Weil es eine Denkweise und keine technik ist.

weil...

Ich lese immer nur Behauptungen und "Du hast nicht recht".

Hä?

"Das ist ein Apfel" -- "Weil?" Was soll man denn dadrauf antworten? Es ist nicht logisch, dass ein Apfel "Apfel" heißt... es ist einfach so.

Shade Of Mine

Xin schrieb:

Entweder ist es "OO" oder nicht "OO".

klingt sehr vereinfacht. warum muss alles schwarz oder weiß sein? kann nicht etwas grau sein?

in c++ habe ich zB programme die teilweise aus reinem C code bestehen - weil es eben alter Code ist, der nach und nach an C++ angepasst wird. Ist jetzt alles OO oder sind nur teile OO oder ist garnichts OO?

Abgesehen davon, dass es bei Dir auch schmutziges OO zu geben scheint, unterscheidest Du wenigstens zwischen OO-Sprache - sie es nicht gibt - und OO-unterstützende Sprachen. Wir sind uns diesbezüglich also einig.

Was ist schmutziges OOP?
Ich betone doch die ganze Zeit, dass OO deine Denkweise ist. Also gibt es in meinen Augen auch keine OO Sprachen.

Wenn du JS programmiert hast - dann erklär mir mal fix wieso du dort keine OO hast. Oder hast du sie doch - wenn ja, dann widersprichst du dir ja, weil es in JS keine virtuellen Funktionen gibt. Es gibt kein dynamisches dispatchen.

Ich sehe hier keine Relevanz. Begründe, warum Du sie siehst.
Für OO muss ich zur Laufzeit auf überschriebene Funktionen zugreifen können, die objekt orientiert ausgewählt werden. Ich muss die Funktionen aber nicht zur Laufzeit austauschen können. Das ist die Baustelle von Reflection.

Warum?
Ich rede nicht von austauschen zur Laufzeit. Ich rede einfach nur von Laden von Klassen zur Laufzeit. Warum ist es Polymorphie wenn ich die Klassen die es gibt doch eh statisch vor mir habe? Wo trennst du ab wann etwas zu statisch für Polymorphie wird.

Nehmen wir das Shape-Circle-Triangle Beispiel. So wirklich toll dynamisch ist es nicht, weil ich ja nur Circle und Triangle habe. Warum ist es dennoch Polymorphie? Schließlich stehen die Klassen zur Compiletime fest die es gibt. Wirklich dynamisch wäre es erst, wenn man zur Laufzeit unendliche neue Klassen nachladen würde.

Worauf ich hinaus will ist: du ziehst einen Trennstrich den es nicht mehr gibt. Moderne VMs wie Java und .NET erlauben es die Compiletime der Runtime gleichzusetzen. Es gibt keine "das ist statisch" und "das ist dynamisch" Situationen mehr. Denn die Kompilierung findet während der Laufzeit statt und ich kann jederzeit neue Elemente nachladen.

Shade Of Mine schrieb:

Überladung gehört zur Polymorphie. Das entspricht meiner Definition.
Überladung ist ein Part der Polymorphie, der nicht für OOP notwendig ist.
Das Überschreiben hingegen ist notwendig. Das könnte ein Grund sein, warum man zwischen Überschreiben und Überladen unterscheidet?

Nach welchen Gesichtspunkten trennst du Polymorphie? Einfach wie du lustig bist...? Du sagst wunderschön dieser Teil ist OO, dieser Teil nicht - aber erklär echt mal wie du JS siehst: es gibt keine Vererbung, keine Polymorphie - es gibt dort nur Objekte.

Vererbung und virtuelle Funktion geht problemlos ohne Klassen, aber nicht ohne Klassifizierung.
C hat keine Klassen und man kann trotzdem OOP verwenden.

Vererbung ist für dich also auch Object Cloning?