Performancemythen?

[otze]

Anmerkung: ich habe bislang nicht wirklich stichhaltige Argumente von Xins Seite gelesen, die einer allgemeineren definition entgegen laufen würden, alles was er sagt beschränkte sich nur auf *sein* Bild.

Und wie kann er denn wirkliche gegenargumente verlangen? In der OOP nach *unserer* definition kann man jedes problem mit vererbung und virtual lösen. Dagegen zu argumentieren ist schwachsinnig, denn dann würden wir unsere eigene Definition entkräften. Eigentlich ist es Xins aufgabe, unsere Definition auf einen Widerspruch zu führen, das kann er aber nicht, ohne seine definition als Bewertungsmaßstab zu führen. Ein "Diese definition deckt sich nicht mit meiner und ist deswegen falsch" ist unlogisch, aber das macht er hier.

Unsere Definition lautet: OOP ist die Modellierung der Interaktion und Abhängigkeit von Objekten. Objekt müssen wir nicht definieren, denn er verlangt keine definition.

[Jester]

Xin, Du magst wissen was ich mit dazuerfinden und ignorieren meine? Bitteschön:
Ich habe erklärt, was ich mit Zusammenfassung von Funktionen und Daten zu Objekten meine (weiter oben habe ich erklärt, wie ich daraus OOP ableite). Daraufhin hast Du dazuerfunden, dass es was mit dem ersten Parameter einer Funktion zu tun hätte. Dann habe ich erklärt was das unterscheidet. Das hast Du ignoriert und mich erneut darauf hingewiesen, dass es ja nur auf den ersten Parameter ankommt.

[rüdiger]

Eigentlich verstehe ich gar nicht, warum wir hier Xins abstruser Definition von OOP so viel Aufmerksamkeit schenken. Das ist eh kein Thema, wo wir auf Einsicht hoffen können (Kategorie: Gegen die Wand reden)! Daher werde ich nun auch weitere Beiträge von Xin und zu Xins merkwürdiger Definition ignorieren! Ich versuche mal lieber die Diskussion auf wesentlich interessantere und vielleicht auch eher zu treffende Definitionen zu lenken, die in dem Thread gefallen sind (und hoffe mal, das einige Leute da mitziehen werden):

DEvent schrieb:

OO eine Denkweise wie man Daten und Methoden gruppieren kann, dabei zeichnet sich die Gruppierung durch die Einteilung in Objekten=Daten+Methoden aus. OOP ist die implementierung von der OO denkweise, die die encapsulation, inheritance, and polymorphism Techniken benutzt.

Wie schon gesagt. Dem ersten Satz stimme ich nicht ganz zu, da es Systeme gibt, die die Methoden nicht in Objekte gruppieren. CLOS arbeitet zum Beispiel ausschließlich über Multimethoden. Beim zweiten Satz hat Apollon schon richtig angemekrt, das es OO-Systeme gibt, die ohne Vererbung, Encapsulation und Polymorphismus auskommen. (War das nicht zB JavaScript?)

overtaker schrieb:

objektorientiert ist, wenn verschiedene objekte miteinander kummunizieren, d.h. nachrichten empfangen und versenden können. <- punkt

Die Definition finde ich eigentlich ziemlich treffend. Es geht um die Kommunikation mit Nachrichten zwischen Objekten. Das schließt so einfach alles ein, was ich bisher als OOP kennen gelernt habe (und auch den Erlang OO Ansatz ;))

...

@Bashar
ha, da musst du schon früher aufstehen, um mich beim Posten von Links über Erlang zu schlagen :p

[evilissimo]

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

Auf der anderen Seite wird versucht eine Abstrakte Definition von Objekt Orientierung (bzw Objekt Orientierter Programmierung zu erstellen welche sich mit der Ansicht von Xin keines Falls vereinbaren lässt.

Ich weiß zwar nicht mehr auf welcher Seite ich das gelesen habe, und welcher Beitrag das genau war. Aber es gab einen Satz in dem Xin mit "... woher soll der Compiler wissen..." argumentiert hat.
Daraus schließe ich das Xin aus sicht des Compilers zu argumentieren versucht.

Der Thread ist aber mal wieder sehr lehrreich. Unteranderem das die Definition von OO zu einem Glaubenskrieg führen kann *g*

Gruß,
Vinzenz

[Undertaker]

evilissimo schrieb:

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

bingo!
~40 seiten nur deshalb, weil alle aneinander vorbei reden.

[Xin]

Jester schrieb:

Xin, Du magst wissen was ich mit dazuerfinden und ignorieren meine? Bitteschön:
Ich habe erklärt, was ich mit Zusammenfassung von Funktionen und Daten zu Objekten meine (weiter oben habe ich erklärt, wie ich daraus OOP ableite). Daraufhin hast Du dazuerfunden, dass es was mit dem ersten Parameter einer Funktion zu tun hätte. Dann habe ich erklärt was das unterscheidet. Das hast Du ignoriert und mich erneut darauf hingewiesen, dass es ja nur auf den ersten Parameter ankommt.

1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.
2. Mir ist keine sinnvolle Erklärung eines Unterschiedes aufgefallen.

evilissimo schrieb:

Ich hab den Thread schon n bisserl verfolgt, aber auch nicht ganz gelesen. Das einzige was sich für mich hier herauskristallisiert ist das Xin scheinbar OOP aus der Sicht eines Compilers beschränkt.

Ich bin praktisch veranlagt. Seit der technischen Umsetzung von Goto haben sich Computer im Konzept und damit in ihren Möglichkeiten nicht weiterentwickelt.

Solange sich da nichts ändert, gibt die Maschine die Möglichkeiten vor. Der Compiler übersetzt unsere Sourcecodes auf die Maschine. Ich orientiere mich an der Maschine. Programme werden objektorientiert gesteuert oder statisch.
"Plain classes" laufen statisch ab, C++-Klassen mit virtual laufen objektorientiert ab - auch auf Ebene der Maschinensprache. Das Schlüsselwort virtual schaltet die OOP-Funktionalität hinzu, das fehlen von virtual in C++ bedeutet, dass man OOP entweder selbst implementieren muss oder darauf verzichtet.

Wer "plain classes" oder "templates für plain classes" bereits als OOP bezeichnen möchte, arbeitet mit einem theoretischen Konstrukt, dass in keinem Zusammenhang mit dem steht, was auf der Maschine bearbeitet wird. Von "eurem OOP" bleibt nach der Übersetzung nichts über, was sich von einem C Programm oder Assemblerprogramm unterscheidet. "plain classes" genießen die Unterstützung von C und auch von Assembler. Meine Form von OOP ist in C oder Asm nicht unterstützt, muss man halt selbst implementiert werden.

Die Maschine ist die Realität mit der ein Entwickler klarkommen muss.
Entsprechend kann man seine Sichtweise an der Realität ausrichten oder sich etwas anderes ausdenken. Das, was man sich anderes ausdenkt, muss aber schlussendlich auf die Maschine übertragen werden und "plain classes" schaffen es nicht bis auf die Maschine.
Die vielen Definitionen, die hier beschrieben wurden und inzwischen schon als "unsere Definition" bezeichnet wird, hat mal Auswirkung auf die Maschine (wenn in C++ virtual verwendet wird), mal nicht.
Viel Spaß mit einem theoretischen Konstrukt.

Ich beende den Thread hiermit.

Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Möge er in Frieden ruhen.

[Apollon]

Xin schrieb:

Ich beende den Thread hiermit. [...] da es in dem Thread vorrangig darum geht gegen mich zu sein...

Glaub mir, so wichtig bist Du nun auch nicht.

[otze]

ging der thread nicht über Performancemythen?

[hustbaer]

Bisher ist es argumentativ nie eng geworden, aber es wird wirklich alles gegen "meine" Definition angekarrt, nur um dagegen zu sein.

Es ist nie eng geworden weil du einfach nicht darauf eingehst was andere schreiben. Ist sehr einfach so seinen Standpunkt zu vertreten.

[rüdiger]

Xin schrieb:

1. Nicht dazuerfunden. Der implizite Parameter ist nicht erfunden, er wird in der Regel mit "this" bezeichnet.

Nö, wie ich schon sagte: Schau dir bitte mal mehr Programmiersprachen an. Deine Einfältigkeit stimmt einen traurig und raubt dir aus meiner Sicht jede Kompetenz eine vernünftige Definition der OO zu treffen.

Xin schrieb:

Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Möge er in Frieden ruhen.

Du bist wirklich Arrogant und eingebildet Wenn du Gegenargument als persönlichen Angriff empfindest ist das einfach nur lächerlich!

[scrub_]

Xin schrieb:

Ich bin praktisch veranlagt. Seit der technischen Umsetzung von Goto haben sich Computer im Konzept und damit in ihren Möglichkeiten nicht weiterentwickelt.

Ne, Du bist praktisch gefangen. Du klebst geradezu an bestimmten konkreten Dingen und kannst keinen Millimeter abstrahieren- daher ist es ja auch nicht verwunderlich, daß Du theoretische Informatiker als "nur theoretisch Informatiker" verhöhnst.

Xin schrieb:

Ich beende den Thread hiermit.
Ihr dürft gerne weiterdiskutieren, da es in dem Thread vorrangig darum geht gegen mich zu sein und ich aussteige, ist der Thread vorraussichtlich in 24 Stunden tot. Ihr dürft jetzt nochmal über meine Ignoranz oder Arroganz herziehen, aber dann widmen wir uns alle wieder Konstruktiverem.

Du bist so unglaublich arrogant. Nur nochmal zur Erinnerung: Du stehst hier nicht vor einem Tutorium, Du bist nicht derjenige, der "hier den Erklärbär spielen" muß. Du schätzt Deine Position völlig falsch ein und benimmst Dich ständig daneben, indem Du anderen Leuten Dummheit, Ignoranz und mehr unterstellt- das führt auch dazu, daß Dich vermutlich niemand leiden kann. Es fällt nicht vom Himmel und liegt auch nicht an Deiner Genialität, sondern Du hast angefangen, andere runterzumachen, und deswegen bist Du unbeliebt. Das ist natürlich keine gute Ausgangslage, wenn man andere überzeugen will. Das hast Du Dir ganz allein zuzuschreiben.

Ich bin übrigens kein Diplominformatiker, werde nie einer sein und finde Deine Definition trotzdem merkwürdig, falls Dich das beruhigt. Falls ich jetzt wieder mal nur von Dir abgeschrieben haben sollte, tut es mir sehr leid.

[Theston]

Beeindruckend, wie eine einzelne Person 40 Seiten lang so konsequent trollen kann.

[Shade Of Mine]

Xin schrieb:

Programme werden objektorientiert gesteuert oder statisch.
"Plain classes" laufen statisch ab, C++-Klassen mit virtual laufen objektorientiert ab - auch auf Ebene der Maschinensprache.

Sehe ich überhaupt nicht. In Assembler Code steht uU so etwas:

void draw(Class* p) {
  switch(p->type) {
  case TRIANGLE_CLASS:
    return triangle_draw(p);
  case CIRCLE_CLASS:
    return circle_draw(p);
  }
  return pure_virtual_function_called_error();
}

Wenn man nun daran OO Code definieren will...

Aber OK, wenigstens habe ich jetzt eine Ahnung was für dich OOP. Wo sich diese "Definition" komplett beißt ist Pseudo Code. Man kann keinen OO-Code skiziieren weil es keinen Compiler gibt der ihn versteht. Naja - ok.

Zu Behaupten seit goto hat sich nichts geändert ist übrigens eine Widerlegung deiner OOP Definition -> da alles eh nur gotos sind, ist jeder Code nur doofer Spaghetti Code.

Lies dir den Thread am besten in 5 Jahren nochmal durch - vielleicht bist du dann weit genug OOP auf einer abstrakteren Ebene zu verstehen.

[Brutus]

Viel beeindruckender ist doch eher, dass er den ganzen Quatsch, den er hier andauernd versucht herunterzubeten, sogar ernst meint. Er ist fest davon ueberzeugt. Mit Trollen hat das schon lange nichts mehr zutun, dennoch vermag mir gerade ein praeziser Begriff dafuer nicht einfallen.

[Undertaker]

Shade Of Mine schrieb:

Zu Behaupten seit goto hat sich nichts geändert ist übrigens eine Widerlegung deiner OOP Definition -> da alles eh nur gotos sind, ist jeder Code nur doofer Spaghetti Code.

das kannste so nicht sagen. nach Xin's definition wäre ein assembler-code mit indirekten sprüngen 'JMP [R0]', d.h. die nächste position des instruction pointers wird zur laufzeit berechnet, durchaus objektorientiert.

[this-*gt*that]

Gabs die letzten 40 Seiten irgend ne brauchbare Erkenntnis?

[Tellerrand]

Mal etwas Anregung für Xin

- Wieso sollte eine Klasse kein Objekt sein?
- Ist ein Objekt was nur einmal im Programm vorkommt nichtmehr OO?

[Undertaker]

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

[evilissimo]

Tellerrand schrieb:

Mal etwas Anregung für Xin

- Wieso sollte eine Klasse kein Objekt sein?
- Ist ein Objekt was nur einmal im Programm vorkommt nichtmehr OO?

Ich sag nur Singleton

[evilissimo]

Undertaker schrieb:

Tellerrand schrieb:

- Wieso sollte eine Klasse kein Objekt sein?

es kommt darauf an, ab wann man etwas als objekt ansieht und ab wann man damit wieder aufhört. in Java (bitte verzeiht dieses wort) z.b. ist eine klasse kein objekt.

LISP ist da dann das gegenbeispiel