Performancemythen?

[otze]

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.

<°)))><|

[rüdiger]

Xin schrieb:

rüdiger schrieb:

Ich will mich gar nicht auf die Ebene begeben, auf der wir uns hier gegenseitig Arroganz, schlechten Diskussionsstil, Kindlichkeit oder ähnliches, vorwerfen.

Ich machte mir vorgestern einen Spaß daraus, mal zu gucken, was alles hinter meinem Rücken geschrieben wird, wenn ich den Chat verlasse und war mit einem zweiten Nick eingeloggt. Du hast Dich als einer der wenigen mit den Worten "Mann ist der dumm" nicht auf diese Ebene begeben.

Ich hab dir in dem Thread sogar vorher schon ganz offen Arroganz vorgeworfen.

[Xin]

rüdiger schrieb:

Xin schrieb:

rüdiger schrieb:

Ich will mich gar nicht auf die Ebene begeben, auf der wir uns hier gegenseitig Arroganz, schlechten Diskussionsstil, Kindlichkeit oder ähnliches, vorwerfen.

Ich machte mir vorgestern einen Spaß daraus, mal zu gucken, was alles hinter meinem Rücken geschrieben wird, wenn ich den Chat verlasse und war mit einem zweiten Nick eingeloggt. Du hast Dich als einer der wenigen mit den Worten "Mann ist der dumm" nicht auf diese Ebene begeben.

Ich hab dir in dem Thread sogar vorher schon ganz offen Arroganz vorgeworfen.

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

[dv]

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.

[Apollon]

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

[Gast]

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 ?

[overtaker]

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.

[das...]

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

[das...]

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.

[erterte]

@das...: Du nervst.

Lasst die Mythen selbiges sein.

[nix merker]

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

[Gast]

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