Performancemythen?

Shade Of Mine schrieb:

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

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

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

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

Xin schrieb:

Tellerrand schrieb:

Mal etwas Anregung für Xin

- Wieso sollte eine Klasse kein Objekt sein?

Und für den Tellerrand, der unfähig war diese bereits mehrfach beschriebene, hoch komplexe Definition von Objekt auf Anhieb zu verstehen,

tja so ein pech aber auch, dass in smalltalk auch klassen objekte sind aber das ist für dich ja offensichtlich weder nach dem 1000ten mal dass dir gesagt wurde dich mit mehr sprachen als java und c++ zu beschäftigen, geschweige denn auf anhieb, zu verstehen

minhen, wieso schreibst Du hier eigentlich noch?! Du hast mir und jedem denkenden Menschen in diesem Thread schon bewiesen, dass Du qualifizierter bist als der Kindergarten hier, der schwammige, sich widersprechenden Definition nutzt, um dann von "selektiver Ignoranz" oder Rumtrollen zu sprechen.

wieso, weil er eine ähnliche meinung als du hast? bei solchen texten brauchst du nich über beleidigungen von dumm und arrogant nicht zu wundern

Apollon

merker schrieb:

Shade Of Mine schrieb:

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

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

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

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

Wie waers mit: Ja? Weil der Sourcecode im Grunde der Bauplan eines Programms ist.

Xin

dv schrieb:

Xin, wie wärs, wenn du endlich aufhörst, gültige Argumente einfach zu ignorieren? CLOS ist nicht von der Hand zu weisen, aber du ignorierst es knallhart, und nennst dann alle unfähig, obwohl viele hier deutlich mehr draufhaben dürften als du. Also. Erleuchte uns mit deinen Antworten zu den vielen hier geposteten Lisp/CLOS/Smalltalk/Objective C-Argumenten. Dann red weiter.

Die Sprachen wurden genannt. Die Nennung von Sprachen steht in keinem Widerspruch zu Stroustrups Definition.
Zu dem Thema wurde von mir und von minhen schon entsprechendes zu gesagt.

Ich habe mich hier häufig genug wiederholt, weder übernehme ich für Dich oder irgendwen das Lesen, um Dir Zitate rauszusuchen, noch sehe ich mich oder minhen in irgendeiner Pflicht, euch weiterhin Dinge vorzubeten, die ihr in Marcus OOP-Buch findet, in den Schriften von Stroustrup oder einfach durch Verwendung eures hoffentlich gegebenen gesunden Menschenverstandes.

Ich amüsiere mich hier lediglich noch über die Leute, die ignorieren, dass bereits alles wichtige gesagt wurde und sich im Recht fühlen, weil sie Dinge vorbringen, die innerhalb der letzten 40 Seiten bereits in der Regel mehrfach geklärt wurden und gleichzeitig diejenigen, die sich an Logik halten und an Definitionen, die Leute aufgestellt haben, die sich ernsthaft mit dem Thema beschäftigt haben, als arrogant und ignorant zu bezeichnen.
Ich kann da mich nur noch drüber amüsieren. Mehr fällt mir dazu nicht mehr ein.

Apollon schrieb:

@Xin: Du bewegst dich auf einer anderen - um nicht zu sagen falschen - Abstraktionsebene. Mach doch mal einen Perspektivenwechsel.

Wir bewegen uns alle auf unseren eigenen Abstraktionsebenen. Manche sehen von Ihrer Ebene die Dinge klar und für die anderen ist die Sicht halt etwas schwammig. Jeder, wie er es mag.
Ich plane keinen Perspektivenwechsel, ich hab' hier gute Sicht und ich sitze im ersten Rang und habe Platz die Beine hochzulegen. Schließlich weigert sich hier die Masse trotz Einladung und ausführlicher Wegbeschreibung, mal drei Schritte weiterzudenken und hier Platz zu nehmen. Einfach mal unbefangen gucken, wie die Sicht hier ist.
Abgesehen davon, dass ich mich damit von euch ausgrenze und mir diverse Beleidigungen anhören darf, sehe ich keinen Nachteil auf fachliche Fragen jedem, der zuhören möchte, klare Antworten geben zu können.

Niemand hat sich auf das Konzept eingelassen, dass in C++ durch virtual ausgedrückt wird, dass in anderen Sprachen ebenso, aber natürlich mit anderer Syntax verwandt, wird. Das Konzept, das OOP genannt wird. Diesen kleinen Schritt der Abstraktion bringt hier kaum jemand fertig, aber jeder freut sich, dass man es geschafft hat, jedem Argument entgegen treten zu können - und das meine ich wirklich in der Form von treten - und sich eine Unmenge an Punkten auszudenken, die nichts mit dem Thema zu tun haben.
Ob das arrogant klingt oder nicht - das hier ist ein Kindergarten.

In diesem Thread war kaum jemand, der zuhören mochte, also sehe ich keinen Bedarf mehr, hier noch irgendwelche Fragen zu beantworten oder etwas zu erklären. Wer was lernen möchte, sollte Marc++us Buch lesen, da steht genau das drin, was ich hier zwischen den ganzen Angriffen erklärte. Vielleicht hilft es dem Verständnis, wenn man nicht so schnell auf "antworten" klicken kann, sondern auch mal eine Seite weiter lesen muss.
Alle anderen dürfen gerne noch ein wenig gegen mich sein, wenn's Spaß macht. Ich habe kein Problem von einem fachlichen Kindergarten abgegrenzt zu werden.

... ist doch echt krass. Xins account wurde doch offensichtlich nur zum reinen trollen und provozieren angelegt. warum ist der account nicht schon längst gesperrt? gibs nich

Xin

das... schrieb:

... ist doch echt krass. Xins account wurde doch offensichtlich nur zum reinen trollen und provozieren angelegt. warum ist der account nicht schon längst gesperrt? gibs nich

Es liegt jedem frei, dies im Subforum Forentechnik beim Admin anzufragen.
Sollte dieser dem zustimmmen, werde ich mich nicht mit einem anderen Nick wieder anmelden.

Undertaker

Xin schrieb:

...werde ich mich nicht mit einem anderen Nick wieder anmelden.

wie lautet denn dein anderer nick?

Xin

Undertaker schrieb:

Xin schrieb:

...werde ich mich nicht mit einem anderen Nick wieder anmelden.

wie lautet denn dein anderer nick?

...werde ich mich nicht mit einem anderen Nick wieder registrieren.

Es gibt keinen anderen Nick in diesem Forum.

Xin schrieb:

das... schrieb:

... ist doch echt krass. Xins account wurde doch offensichtlich nur zum reinen trollen und provozieren angelegt. warum ist der account nicht schon längst gesperrt? gibs nich

Es liegt jedem frei, dies im Subforum Forentechnik beim Admin anzufragen.

um in diesem forum zu schreiben muss man leider registriert sein aber ich werd mich hüten mich hier zu registrieren solang noch solche wie du hier schreiben.

@das...: Du nervst.

Lasst die Mythen selbiges sein.

merker schrieb:

Shade Of Mine schrieb:

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

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

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

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

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

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

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

nix merker schrieb:

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

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

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

minhen

rüdiger schrieb:

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

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

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

Xin schrieb:

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

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

minhen, wieso schreibst Du hier eigentlich noch?!

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

rüdiger

minhen schrieb:

rüdiger schrieb:

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

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

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

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

Xin hatte behauptet, das Multimethoden nicht OOP seien.

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

Bei

struct A {
  void a();
};

A a;
a.a();

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

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

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

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

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

struct A {
  void a();
};
A a;
a.a();

Ist ja sehr wohl nach deiner Definition Objektorientiert, wenn ich es mit einem C++-Interpreter ausführe. Genau wie

#include <cstdio>
using std::printf;
class A { };
int printf(A, ...);

int main() {
  printf("hallo welt");
  A a;
  printf(a);
}

Ist in einem C++-Interpreter nach eurer Definition ebenfalls Objektorientiert.

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

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

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

Xin schrieb:

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

oder vielleicht eher solche Comments?

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

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

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

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

etc.

valaBoo

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

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

MfG
valaBoo

minhen

rüdiger schrieb:

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

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

minhen schrieb:

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

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

Nein. Zur Erklärung lese meinen vorigen Beitrag.

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

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

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

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

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

Xin

rüdiger schrieb:

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

Xin hatte behauptet, das Multimethoden nicht OOP seien.

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

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

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

rüdiger schrieb:

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

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

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

Und wen interessiert Dein komischer Interpreter überhaupt?!

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

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

rüdiger schrieb:

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

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

rüdiger schrieb:

Xin schrieb:

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

oder vielleicht eher solche Comments?

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

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

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

minhen schrieb:

minhen, wieso schreibst Du hier eigentlich noch?!

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

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

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

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

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

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

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

otze

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

hat sich die gegenseite auch

<°(((><|

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

Shade Of Mine

Xin schrieb:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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