Performancemythen?

[Xin]

Shade Of Mine schrieb:

Xin schrieb:

Ein Compiler kann ein Interface nicht wegoptimieren, da er ansonsten die Semantik des Programms ändert.

Äh... Das ist aber falsch. Die Semantik ändert sich garnicht wenn er dennoch die richtigen Methoden aufruft.

Beispiel: [...]
macht ist das aber korrekt. Die Semantik ändert sich nicht.[/cpp]

Witziges Beispiel.
Das funktioniert aber auch nur, wenn garantiert wird, dass die Objektvielfalt beschränkt ist, eine Bedingung, die OOP nicht verlangt. Im Gegenteil - der Zweck von OOP ist ja eben, die Objektvielfalt nicht zu beschränken.
In Deinem Fall beschränkst Du die Objektvielfalt in dem Algorithmus auf A und B.
Wenn das für den Algorithmus reicht, kann es sinnvoll sein OOP aus dem Algorithmus herauszunehmen.

Da nun das Interface fehlt, kannst Du nun keine Algorithmen mehr schreiben, die nur mit Objekten arbeiten, Du musst alles auf A oder B spezialisieren. Und genau das, soll OOP ja vermeiden.

Eine Factory baust Du mit Deinem zweiten Beispiel jedenfalls nicht mehr, ohne böswillig zu casten.
Wenn Du die Funktion main in Factory() umbenennst und sie das erzeugte Objekt zurückgeben lässt, bekommst Du Schwierigkeiten, weil die Objekte ohne Interface nicht mehr verwandt sind.

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

Shade Of Mine schrieb:

Auch optimieren C++ Compiler oft virtuelle Methoden aufrufe weg.
Solange sich das Programm immer noch gleich verhält, ergo: korrekte Resultate liefert - kann der Compiler machen was er will.

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

Shade Of Mine schrieb:

Ein Objekt entspricht einem Interface, wenn es die zum diesem Interface gehörenden Funktionen beschreibt. JavaScript bietet aber keine Möglichkeit dies automatisch zu prüfen.

Und das ist der Punkt:
verlangt OOP Typsicherheit?

Ich quote dann mal aus dem vorherigen Posting:

Xin schrieb:

Typsicherheit ist eine Voraussetzung für korrekte Programme. Die Kontrolle der Typsicherheit ist keine Voraussetzung für OOP.

OOP-Programme reagieren genauso undefiniert, wie andere Programme, wenn Elemente mit dem falschen Typ angesprochen werden.

Shade Of Mine schrieb:

Typsicherheit ist ein relevanter Punkt für jegliche Form des Programmierens, auch in schwach typisierten Sprachen.

Wie kann ich Typsicherheit ohne Typen haben?

Dafür musst Du dann als Programmierer selbst sorgen. Wenn Du Dich vertust, knallt's halt. Die Sprache hat eben nicht die Möglichkeit, Dich vor solchen Fehlern zu warnen.

Shade Of Mine schrieb:

Typsicherheit ist eine Voraussetzung für korrekte Programme. Die Kontrolle der Typsicherheit ist keine Voraussetzung für OOP.

Also ist der JS Code doch OO?

In JS ist überhaupt nichts statisch. Wenn Du das Interface garantieren kannst und damit Objekte austauschbar machen kannst, arbeitest Du objektorientiert.
Ob der JS-Code OO ist, weiß ich nicht, da ich nicht weiß, was der JS-Code ist.

Shade Of Mine schrieb:

Über deine Definition von Typsicherheit will ich mal nicht reden...

Warum nicht? Das liest sich schon wieder wie ein Vorwurf. Genauso wie mir der Satz zuvor 'ich müsse zugeben', mißfällt bei Dingen, die ich nicht bestreite. Ich muss nichts zugeben, ich stimme zu - da besteht ein Unterschied.

Shade Of Mine schrieb:

Du kannst Dynamo und Atomreaktor zur Laufzeit nicht austauschen, weil die Programmsteuerung durch den Referenztyp kontrolliert wird und nicht durch den Objekttyp: kein OOP.

Kann ich wohl. Ich nehm einfach einen C++ Interpreter oder eine Bindung von C++ an die .NET/Java VM und schon kann ich es.

Du kannst so zum Beispiel keine Klassen aus Plugins nachladen, wenn Du nur ein "template Plugin" hast. Ohne ein Interface Plugin, geht hier nichts. Aus diesem Grund darf ein Compiler auch nicht ungefragt ein Interface herausoptimieren.

Kann ich Problemlos machen: C++ Interpreter oder Java VM/.NET VM Anbindung und ich kann das machen. Es ist einfach nur ein kleines technisches Problem: nichts konzeptuelles.

Interpreter, Java und .NET haben das Problem, dass sie selten statisch ablaufen. ^^
Erlaubt C++/CLI überhaupt die übersetzung, ohne ungefragt 'virtual' hinzuzufügen?

Es gibt ja nicht nur die Frage, ob ein Programm OO ist, sondern auch umgekehrt: Welche Möglichkeiten gibt es OO zu vermeiden?

Shade Of Mine schrieb:

Solange nur zur Laufzeit kompiliert ändert sich nichts. Wird das Programm zur Laufzeit modifiziert, entscheidet sich auch zur Laufzeit, ob ein OOP Zugriff stattfindet oder nicht.

Also definiert sich OOP daran welchen Compiler Schalter ich aktiviere?

Hat die Frage etwas mit der Aussage zu tun!?

Wenn Du zur Laufzeit ein Programm B schreibst, dann entscheidest Du zwangsläufig zur Laufzeit des Programms A, ob Programm B OOP verwenden wird oder nicht.

Shade Of Mine schrieb:

Das mit JavaScript habe ich noch nicht verstanden:
wenn ich es nach Java kompiliere, sprich diese Interfaces einbaue - ist es OOP - richtig?
Wenn ich es aber zur Laufzeit interpretiere - ist es dann OOP? Natürlich gehe ich von einem korrekten Programm aus.

Du kompilierst also JavaScripts mit Java...?

Die Antwort auf Deine Frage findest Du bereits in diesem Posting.
Ansonsten gehe ich jetzt die Alarmglocken für besonders qualifizierte Posting abstellen.

Overtaker schrieb:

rüdiger schrieb:

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

sag ich ja, sieg

Ich will euch euren Sieg nicht nehmen. Viel Spaß damit.
Wenn man ihn nur laut genug propagiert, kann man damit sogar amerikanischer Präsident werden.

Overtaker schrieb:

was auch lustig ist:

Xin auf seite 34 schrieb:

Lass es mich anders formulieren: Das eigene Hirn zu nutzen bringt mehr, als Texte zu zitieren, ohne zu wissen, ob die jeweiligen Autoren ihr Hirn benutzt haben oder nur von jemand anderem abgeschrieben haben.

aber auf den letzten seiten nur zitate von herrn strostrup

Ich habe mir seine Argumentationen durchgelesen und mein Hirn benutzt und daraufhin meine Definition von OOP von dem was ihr schreibt auf das was Stroustrup schreibt geändert.
Lustig, nicht? ^^

[Wie die Krähen]

... Die aufeinander rumhacken, obwohl es mit ein wenig menschenverstand schnell gelöst wär.
Man stelle sich einfach mal ein Treffen zwischen den opponenten vor, die dann sachlich ihre argumente vortragen, und dann verbal z.B. auf etwaigem nicht-beantworten einer frage reagieren und sich nach kurzer zeit einer lösung annähern und diese finden, anstatt 50 seiten gefüllt mit sticheleinen, und teils massiven beleidungen abliefern. Und wenns doch nicht klappt dann kloppen sich halt alle...

[minhen]

@Shade Of Mine:
Warum Laufzeit-Polymorphie habe ich gerade erst ausführlich beantwortet. Und dass Laufzeit-Polymorphie aus der Definition der Programmiersprache folgt und daher interpretor- und compilerunabhängig ist, habe ich sogar eben erst gesagt.
Du musst natürlich nicht lesen, was ich schreibe. Aber erwarte nicht, dass ich mich ständig wiederhole, nur weil du die Beiträge nicht liest.

rüdiger schrieb:

Es gibt ja eh keinen logischen Grund statische Polymorphie aufzunehmen oder auszuschließen (ansonsten nenne ihn bitte einer, damit wir die Diskussion begraben können! :)).

Es gibt einen Grund statische Polymorphie auszuschließen und das ist die fehlende Orientierung am Objekt. Auch das habe ich mehrmals genannt und begründet. Auch hier werde ich mich nicht ständig wiederholen.

btw. nach der Stroustrup OO Definition dürfte CLOS gar nicht OO sein, da es keine encapsulation bietet.

Ich programmiere nicht mit CLOS. Ich traue Stroustrup jedoch zu nicht einfach etwas zu behaupten, wenn es keine ausreichende Grundlage dafür gibt.

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

Es ist schon klar warum dir ein eher schwammiges Verständnis lieber ist. Schließlich kann man sich dort alles mögliche vorstellen. So funktionieren Definitionen aber nicht.
Stroustrups Definition dagegen ist sehr durchdacht, erfasst Ähnlichkeiten und Unähnlichkeiten solide und sicher, ist präzise definiert und stellt dadurch unterm Strich einen Wissensgewinn dar. Damit leistet diese Definition etwas, was "Nachrichten verschicken" nicht leistet: sie ist praktisch und brauchbar.

Zum Thema Definitionen kann man auch Alan Kay aus dem Jahr 2004 zitieren:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

Man kann also annehmen, dass nach Alan Kay weder C++ noch Java objekt-orientiert sind. Ist das eine brauchbare Definition? Offensichtlich nicht. Sie ist zwar nicht präzise, seinem Verständnis nach aber eindeutig zu speziell. Und insofern hat sie mit der hier oft vertretenen zu allgemeinen Defintion eine Sache gemeinsam: sie erfasst reale Ähnlichkeiten und Unähnlichkeiten nicht brauchbar.

[Undertaker]

Wie die Krähen schrieb:

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

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

[minhen]

Undertaker schrieb:

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

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

[Shade Of Mine]

Xin schrieb:

Witziges Beispiel.
Das funktioniert aber auch nur, wenn garantiert wird, dass die Objektvielfalt beschränkt ist, eine Bedingung, die OOP nicht verlangt. Im Gegenteil - der Zweck von OOP ist ja eben, die Objektvielfalt nicht zu beschränken.
In Deinem Fall beschränkst Du die Objektvielfalt in dem Algorithmus auf A und B.
Wenn das für den Algorithmus reicht, kann es sinnvoll sein OOP aus dem Algorithmus herauszunehmen.

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

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

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

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

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

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

Und warum ist der Template Code:

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

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

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

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

Warum nicht? Das liest sich schon wieder wie ein Vorwurf. Genauso wie mir der Satz zuvor 'ich müsse zugeben', mißfällt bei Dingen, die ich nicht bestreite. Ich muss nichts zugeben, ich stimme zu - da besteht ein Unterschied.

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

Du kannst so zum Beispiel keine Klassen aus Plugins nachladen, wenn Du nur ein "template Plugin" hast. Ohne ein Interface Plugin, geht hier nichts. Aus diesem Grund darf ein Compiler auch nicht ungefragt ein Interface herausoptimieren.

Kann ich wohl. Und was der Compiler optimiert ist egal - solange der Code dann noch richtig läuft. Er kann zB 2 Klassen anlegen: eine die das Interface implementiert und eine die das nicht tut.

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

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

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

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

Wo denn?

Es gibt ja nicht nur die Frage, ob ein Programm OO ist, sondern auch umgekehrt: Welche Möglichkeiten gibt es OO zu vermeiden?

Shade Of Mine schrieb:

Solange nur zur Laufzeit kompiliert ändert sich nichts. Wird das Programm zur Laufzeit modifiziert, entscheidet sich auch zur Laufzeit, ob ein OOP Zugriff stattfindet oder nicht.

Also definiert sich OOP daran welchen Compiler Schalter ich aktiviere?

Hat die Frage etwas mit der Aussage zu tun!?

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

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

Du kompilierst also JavaScripts mit Java...?

Warum nicht? Was spricht dagegen?

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

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

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

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

[rüdiger]

minhen schrieb:

rüdiger schrieb:

Es gibt ja eh keinen logischen Grund statische Polymorphie aufzunehmen oder auszuschließen (ansonsten nenne ihn bitte einer, damit wir die Diskussion begraben können! :)).

Es gibt einen Grund statische Polymorphie auszuschließen und das ist die fehlende Orientierung am Objekt. Auch das habe ich mehrmals genannt und begründet. Auch hier werde ich mich nicht ständig wiederholen.

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

minhen schrieb:

btw. nach der Stroustrup OO Definition dürfte CLOS gar nicht OO sein, da es keine encapsulation bietet.

Ich programmiere nicht mit CLOS. Ich traue Stroustrup jedoch zu nicht einfach etwas zu behaupten, wenn es keine ausreichende Grundlage dafür gibt.

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

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

Es ist schon klar warum dir ein eher schwammiges Verständnis lieber ist. Schließlich kann man sich dort alles mögliche vorstellen. So funktionieren Definitionen aber nicht.
Stroustrups Definition dagegen ist sehr durchdacht, erfasst Ähnlichkeiten und Unähnlichkeiten solide und sicher, ist präzise definiert und stellt dadurch unterm Strich einen Wissensgewinn dar. Damit leistet diese Definition etwas, was "Nachrichten verschicken" nicht leistet: sie ist praktisch und brauchbar.

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

Zum Thema Definitionen kann man auch Alan Kay aus dem Jahr 2004 zitieren:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I'm not aware of them.

Man kann also annehmen, dass nach Alan Kay weder C++ noch Java objekt-orientiert sind. Ist das eine brauchbare Definition? Offensichtlich nicht. Sie ist zwar nicht präzise, seinem Verständnis nach aber eindeutig zu speziell. Und insofern hat sie mit der hier oft vertretenen zu allgemeinen Defintion eine Sache gemeinsam: sie erfasst reale Ähnlichkeiten und Unähnlichkeiten nicht brauchbar.

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

[Undertaker]

minhen schrieb:

Undertaker schrieb:

da ist mir die (hier schon 2 oder 3 mal genannte definition) schon lieber: 'OOP ist, wenn objekte untereinander nachrichten austauschen'.

Es ist schon klar warum dir ein eher schwammiges Verständnis lieber ist. Schließlich kann man sich dort alles mögliche vorstellen. So funktionieren Definitionen aber nicht.

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

minhen schrieb:

Stroustrups Definition dagegen ist sehr durchdacht, erfasst Ähnlichkeiten und Unähnlichkeiten solide und sicher, ist präzise definiert und stellt dadurch unterm Strich einen Wissensgewinn dar. Damit leistet diese Definition etwas, was "Nachrichten verschicken" nicht leistet: sie ist praktisch und brauchbar.

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

[minhen]

rüdiger schrieb:

Nach meiner Ansicht findet eine Orientierung am Objekt statt, nur eben zu eine Zeitpunkt, an dem das Objekt noch nicht zwangsläufig existiert.

Das Problem mit deiner Kritik war, dass sie logisch unzulässig ist. Du hast dein Verständnis von Objekt genommen und damit versucht einen Teil der OOP-Definition zu widerlegen. Sinnvoll kann man eine Definition aber nur entweder von Innen oder von Außen angreifen. Das heißt, will man die Orientierung am Objekt angreifen, dann muss man auch die Definition von Objekt verwenden. Man kann nicht einfach den Kern der Definition durch das eigenes Verständnis austauschen und sich dann freuen, dass der Rest der Definition damit nicht mehr funktioniert.
Du kommst mir jetzt zwar entgegen, indem du zugestehst, dass das Objekt nicht existiert und machst mir die Antwort damit leicht ("man kann sich nicht an etwas orientieren, das nicht existiert"), aber so ganz scheinst du dich von "deiner Ansicht" bei der Kritik noch nicht getrennt zu haben.
Dabei geht es nicht darum, die Definition für sich selbst zu übernehmen, sondern nur darum, dass man für einen Angriff von Innen auch innerhalb der Definition argumentieren muss.

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

Die Begriffe, die Stroustrup in seiner Definition verwendet, sind doch wohl eindeutig klarer als ein ominöses "Nachrichten verschicken". Was heißt Nachricht? Was heißt verschicken? Sind meine alten C-Programme, in denen ich mit dem Betriebssystem als Boten an das Betriebssystem selbst, an Teile meines Programmes, an Threads und an andere Prozesse Nachrichten verschickt habe, auch objekt-orientiert? Diese Dinge sind doch sogar eindeutig gekapselt. Oder ist jeder Funktionsaufruf, der einem struct gilt, ebenfalls objekt-orientiert? Ist also jedes C-Programm mit nicht-primitiven Datenstrukturen automatisch objekt-orientiert? Und warum diese Fixierung auf statische Polymorphie? Was genau ist daran objekt-orientiert? Zudem drück ich auf "Kompilieren" und schon ist die statische Polymorphie weg. Im Gegenteil dazu die Laufzeit-Polymorphie, die man einfach nicht wegbekommt (sehr deutlich war's doch bei unseren Beispielen, wo man die Klassennamen zur Laufzeit in der Konsole eingeben musste).
Warum also die Fixierung auf statische Polymorphie? Was ist daran objekt-orientiert? Warum darf man den konzeptuellen Unähnlichkeiten nicht auch begrifflich Rechnung tragen? Warum muss alles Gute objekt-orientert sein? Warum darf man zu Templates nicht generische Programmierung sagen, sondern muss sie zur Objekt-Orientierung rechnen?
Langsam dämmert mir, weshalb Stroustrup permanent betont, dass OOP nicht einfach "eine tolle Sache" bedeutet. Denn hier wird OOP wohl auch primär als Synonym zu "tolle Sache" verstanden. Und deshalb müssen dann auch alle tollen Sachen, die objekt-orientierte Sprachen so bieten, auch und obwohl sie konzeptuell völlig verschieden sind, unbedingt vom Begriff OOP erfasst werden. Nur bedeutet OOP eben nicht "tolle Sache" sondern Objekt-Orientierung. Für die anderen tollen Sachen, die konzeptuell verschieden sind, gibt es auch andere Bezeichnungen. Generische Programmierung zum Beispiel.
Daran liegt ja auch grade der Sinn einer Terminologie. Der Sinn den Sachen Namen zu geben ist der, dass man sich über die Konzepte unterhalten kann. Shade of Mine, pale dog, wenn man einem Konzept die Definition verweigert, kann man auch nicht mehr sinnvoll davon und darüber sprechen.

Kann sie zu speziell sein? Aus deiner Sicht ja. Aus meiner Sicht ist deine Definition auch zu speziell, da sie nach Möglichkeit Systeme ausschließt.

Nein, sie schließt eben nicht zuviel Systeme aus sondern erfasst genau die richtigen. Was die schwammige oder mystische Definition dagegen macht wäre in der Statistik auf den Beta-Fehler zu optimieren und dafür einen riesigen Alpha-Fehler in Kauf zu nehmen (man versucht alle falsch-negativen Ergebnisse auszuschließen und nimmt dafür eine riesige Zahl falsch-positiver in Kauf).

[Tellerrand]

Das muss ich einfach zitieren, hat mir meinen Montag gerettet ... danke

Xin schrieb:

Klingt sinnvoll.

Meine Definition von Objekt ist alles außer void.
Meine Definition von Objekttyp ist der Datentyp des Objektes.

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, hier noch etwas zusätzliche Anregung.

Also nochmal:
Warum sollte der Objekttyp kein Objekt sein?
Oder anderst gefragt, ist der Objekttyp ein Objekt?

Und wie behandelst du Sprachen in denen der Objekttyp einem Objekt gleichgestellt ist?

... die Aussage "a ist ein Objekt (weil nicht void), der Objekttyp ist ClassOfA." beantwortet die Frage einfach nicht!

[Tellerrand]

Für eine Definition spielt es keine Rolle welche Dinge sie erfasst.
Eine Definition soll nur Kriterien aufstellen um irgendeine Aussage treffen zu können.
Eine Definition ist im dem Sinne nur das sprachliche Mittel des Vorurteils.

Kann man eine Definition durch Worte wie "zu speziell" oder "zu schwammig" bewerten?

Da fällt mir wieder ein Kay Zitat ein:
"Da meldete sich Alan Kay zu Wort und hakte nach: »Diese Sprache unterstützt also keine Vererbung?« »Das ist korrekt.« »Und sie unterstützt keine Polymorphie?« »Das ist korrekt.« »Und sie unterstützt auch keine Datenkapselung?« »Das ist ebenfalls korrekt.« »Dann scheint mir das keine objektorientierte Sprache zu sein.« Der Vortragende meinte darauf: »Nun, wer kann schon genau sagen, was nun objektorientiert ist und was nicht.« Woraufhin Alan Kay zurückgab: »Ich kann das. Ich bin Alan Kay, und ich habe den Begriff geprägt."
Denny Crain lässt grüßen

[Xin]

Tellerrand schrieb:

Das muss ich einfach zitieren, hat mir meinen Montag gerettet ... danke

Bitte. Dein Zitat lässt mich allerdings zweifeln, ob noch was zu retten ist.

Tellerrand schrieb:

Xin schrieb:

Meine Definition von Objekt ist alles außer void.

Also nochmal:
Warum sollte der Objekttyp kein Objekt sein?
Oder anderst gefragt, ist der Objekttyp ein Objekt?

Und wie behandelst du Sprachen in denen der Objekttyp einem Objekt gleichgestellt ist?

... die Aussage "a ist ein Objekt (weil nicht void), der Objekttyp ist ClassOfA." beantwortet die Frage einfach nicht!

Lies es Dir nochmal in Ruhe durch und denk da einfach nochmal ganz drüber nach. Meditiere, füge Mittelfinger und Daumen zusammen und sage "Ooohmmm...". Schließe die Augen. Vertrau mir, wenn Du gut nachdenkst, wirst Du feststellen, dass Du die Lösung bereits weißt. Wenn Du Deine Frage bis zum Ende liest, wirst Du sehen, dass Du wieder am Anfang stehst und feststellen, dass die Antwort auf Deine Frage, die Antwort auf OOP, ein geschlossener Kreis ist.
Und weil "void" da außen vorsteht, hat "void" in meiner Sprache einen vergleichbaren Stellenwert wie "goto".

Solltest Du im Meditieren nicht ausreichend geübt sein, so dass Du nicht zu einem Erfolgserlebnis gelangst, heißt das Google-Stichwort "type_info".

War das jetzt arrogant? Ich denke, wenn Fragen so blöd gestellt werden, besteht kein Bedarf an einer direkten Antwort. Eigentlich schreit das nach einer ebenso blöden Antwort und immerhin bekommt er insgesammt drei Anleitungen, wie er die Antwort findet.
Nach sovielen direkten Antworten, habe ich mein Soll für Erklärungen an minhen abgegeben, der - im Gegensatz zu mir - noch über eine bemerkenswerte Geduld verfügt.

Gerald M. Weinberg schrieb:

Unter den wichtigsten Eigenschaften der Persönlichkeit eines Programmierers gehört auch ein Sinn für Humor. Der Computer macht uns alle zu Idioten, denn das "Ach, ich Idiot"-Erlebnis kann niemand von uns vermeiden. Umso besser ist es, wenn man auch über sich selbst lachen kann, denn sonst lässt sich auf Dauer das Programmieren nicht ertragen. Die Nationalhymne des Programmierers sei "aaaaaaaaaahhhhh", heißt es scharfsinnig. [...] Nur, wenn wir die zweite Strophe "ha ha ha ha ha" auch singen, können wir dauerhaft die Rolle des Clowns spielen.

aus "Die Psychologie des Programmierers", S276

Tellerrand, wenn Du meditiert hast, entscheide Dich. Wenn Du bis zur zweiten Strophe kommst, ist der Montag vielleicht doch noch zu retten.
Viel Erfolg.

[rüdiger]

minhen schrieb:

rüdiger schrieb:

Nach meiner Ansicht findet eine Orientierung am Objekt statt, nur eben zu eine Zeitpunkt, an dem das Objekt noch nicht zwangsläufig existiert.

Das Problem mit deiner Kritik war, dass sie logisch unzulässig ist. Du hast dein Verständnis von Objekt genommen und damit versucht einen Teil der OOP-Definition zu widerlegen. Sinnvoll kann man eine Definition aber nur entweder von Innen oder von Außen angreifen. Das heißt, will man die Orientierung am Objekt angreifen, dann muss man auch die Definition von Objekt verwenden. Man kann nicht einfach den Kern der Definition durch das eigenes Verständnis austauschen und sich dann freuen, dass der Rest der Definition damit nicht mehr funktioniert.
Du kommst mir jetzt zwar entgegen, indem du zugestehst, dass das Objekt nicht existiert und machst mir die Antwort damit leicht ("man kann sich nicht an etwas orientieren, das nicht existiert"), aber so ganz scheinst du dich von "deiner Ansicht" bei der Kritik noch nicht getrennt zu haben.
Dabei geht es nicht darum, die Definition für sich selbst zu übernehmen, sondern nur darum, dass man für einen Angriff von Innen auch innerhalb der Definition argumentieren muss.

statische Polymorphie ist ja im Grunde nur bei statischem Typing möglich. Statisches Typing verrät eben Eigenschaften über die Absichten und Zukunft. Daher kann ich auch Dinge wissen über Objekte, die noch gar nicht existieren. Das wird ja auch bei der dynamischen Polymorphie benutzt. Entweder in dem sie zum Beispiel wegoptimiert wird oder in dem der Compiler direkt weiß ob die Nachricht akzeptiert wird und an welcher Stelle im Objekt der Zeiger zur eigentlichen Funktion existiert. Bei JS zum Beispiel wird der Interpreter bei dem Objekt eine Anfrage stellen, ob die Nachricht akzeptiert wird etc.

Statisches Typing ist quasi die Quantenphysik der OOP

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

Die Begriffe, die Stroustrup in seiner Definition verwendet, sind doch wohl eindeutig klarer als ein ominöses "Nachrichten verschicken". Was heißt Nachricht? Was heißt verschicken? Sind meine alten C-Programme, in denen ich mit dem Betriebssystem als Boten an das Betriebssystem selbst, an Teile meines Programmes, an Threads und an andere Prozesse Nachrichten verschickt habe, auch objekt-orientiert?

Ja natürlich. Siehe auch das Post über Erlang. Lass uns mal nachschauen, wie sich das mit deiner Definition verhält:

1. Vererbung: Ja, die existiert zumindest bei Prozessen. Ein neuer Prozess erbt ja die Eigenschaften des Elternprozesses
2. Encapsulation: Ja, die existiert zumindest bei Prozessen/Kernel.
3. Laufzeit Polymorphie: Ja, die existiert. Nachrichten werden erst zur Laufzeit an den Prozess/Kernel dispatcht.
=> Wunderbar OO

Oder ist jeder Funktionsaufruf, der einem struct gilt, ebenfalls objekt-orientiert? Ist also jedes C-Programm mit nicht-primitiven Datenstrukturen automatisch objekt-orientiert?

Wenn das struct ein Objekt ist. Warum nicht. Ist ja auch kein Problem anhand dessen Vererbung, Encapsulation oder Laufzeit Polymorphie zu erstellen.

Und warum diese Fixierung auf statische Polymorphie? Was genau ist daran objekt-orientiert? Zudem drück ich auf "Kompilieren" und schon ist die statische Polymorphie weg. Im Gegenteil dazu die Laufzeit-Polymorphie, die man einfach nicht wegbekommt (sehr deutlich war's doch bei unseren Beispielen, wo man die Klassennamen zur Laufzeit in der Konsole eingeben musste).
Warum also die Fixierung auf statische Polymorphie? Was ist daran objekt-orientiert? Warum darf man den konzeptuellen Unähnlichkeiten nicht auch begrifflich Rechnung tragen? Warum muss alles Gute objekt-orientert sein? Warum darf man zu Templates nicht generische Programmierung sagen, sondern muss sie zur Objekt-Orientierung rechnen?

Ein Template ist generische Programmierung. Das will ich ja gar nicht bestreiten. Es muss auch nicht alles gute OO sein. Funktionale Programmierung ist zB nicht OO und sehr gut :p

Kann sie zu speziell sein? Aus deiner Sicht ja. Aus meiner Sicht ist deine Definition auch zu speziell, da sie nach Möglichkeit Systeme ausschließt.

Nein, sie schließt eben nicht zuviel Systeme aus sondern erfasst genau die richtigen. Was die schwammige oder mystische Definition dagegen macht wäre in der Statistik auf den Beta-Fehler zu optimieren und dafür einen riesigen Alpha-Fehler in Kauf zu nehmen (man versucht alle falsch-negativen Ergebnisse auszuschließen und nimmt dafür eine riesige Zahl falsch-positiver in Kauf).

ob es genau die richtigen sind, ist fragwürdig.

[Gast]

rüdiger schrieb:

minhen schrieb:

btw. nach der Stroustrup OO Definition dürfte CLOS gar nicht OO sein, da es keine encapsulation bietet.

Ich programmiere nicht mit CLOS. Ich traue Stroustrup jedoch zu nicht einfach etwas zu behaupten, wenn es keine ausreichende Grundlage dafür gibt.

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

Das wird minhen nicht gelingen, denn er wird ziemlich schnell auf das MOP stossen und dort Moeglichkeiten entdecken, Zugriffe auf Slots einzuschraenken und damit encapsulation zu erzwingen.

[minhen]

Tellerrand schrieb:

Kann man eine Definition durch Worte wie "zu speziell" oder "zu schwammig" bewerten?

Ja, kann man.
Das Problem ist mir auch schon sowohl hier als auch bei universitären Informatik-Veranstaltungen aufgefallen. Ein Verständnis von Wissenschaft als solche spielt dort keine Rolle. Das führt aber dazu, dass, sobald man etwas nicht mathematisch beweisen kann, man orientierungslos ist und keinen Maßstab mehr hat um etwas zu bewerten. Dort kann die Wissenschaftstheorie helfen indem sie Bewertungsmaßstäbe zur Verfügung stellt. Mit diesen kann man dann in der Tat auch zwischen "besseren" und "schlechteren" Definitionen unterscheiden.

rüdiger schrieb:

statische Polymorphie ist ja im Grunde nur bei statischem Typing möglich. Statisches Typing verrät eben Eigenschaften über die Absichten und Zukunft. Daher kann ich auch Dinge wissen über Objekte, die noch gar nicht existieren.

Das Problem damit ist halt, dass man, wie du selbst sagst, kein Objekt dafür braucht. Das Ding nennt sich aber Objekt-Orientierung und nicht Klassen-Orientierung und auch nicht Typ-Orientierung. Welchen Sinn hat es etwas objekt-orientiert zu nennen, wenn es etwas ist, was kein Objekt hat und auch nicht benötigt?

Ja natürlich. Siehe auch das Post über Erlang. Lass uns mal nachschauen, wie sich das mit deiner Definition verhält:

1. Vererbung: Ja, die existiert zumindest bei Prozessen. Ein neuer Prozess erbt ja die Eigenschaften des Elternprozesses
2. Encapsulation: Ja, die existiert zumindest bei Prozessen/Kernel.
3. Laufzeit Polymorphie: Ja, die existiert. Nachrichten werden erst zur Laufzeit an den Prozess/Kernel dispatcht.
=> Wunderbar OO

Ich weiß doch, dass nach deinem Verständnis so ziemlich alles objekt-orientiert ist. Das ist ja gerade der zentrale Punkt.
Aber verwende dazu doch bitte nicht die OOP-Definition. Vererbung ist schließlich als Mechanismus definiert mit dem aus einer Abstraktion eine neue erzeugt werden kann (sogar ohne die alte ändern zu müssen). Das trifft offensichtlich nicht auf Prozesse zu. Ein laufender Prozess ist keine Abstraktion und dient einem Kindprozess auch nicht als funktionale "Bauvorlage", welche durch das Kind spezialisiert wird.

[Mr. N]

@minhen: Wenn man glaubt, man könne OOP in Implementation oder spezifizierbarem Verhalten definieren, dann stößt man vermutlich zwangsläufig auf Xins Definition, auch wenn die - und darauf reiten die Leute hier rum, ziemlich auf statische Sprachen fixiert ist. Die Alternative ist aber nicht, "alles und jeden als OOP" anzusehen, sondern OOP als Ansatz, als Einstellung zu definieren. Die Notwendigkeit das zu tun ergibt sich ja schon aus der enormen Unterschiedlichkeit der Sprachen, die OOP (mal besser, mal schlechter) unterstützen.

[minhen]

Man kann OOP entsprechend definieren. Sehr gut sogar. Siehst du doch. Und was zum Geier meinst du mit statischen Sprachen? Und wie kommst du darauf die Definition wäre nur auf derartiges beschränkt? Und die Definition von OOP definiert nur OOP, weswegen auch ziemlich unterschiedliche Sprachen der Definition nach objekt-orientiert sind. Lisp ist eine solche Sprache und C++ ist eine solche Sprache. Um nur zwei Beispiele zu nennen, die schon genannt wurden ...

[Mr. N]

minhen schrieb:

Man kann OOP entsprechend definieren. Sehr gut sogar.

Denke ich nicht. Aber nehmen wir an, es wäre so. Selbst dann würde ich mich an die Einstellung-und-Ansatz-Definition halten, weil die einfach vernünftig und üblich ist.

[rüdiger]

minhen schrieb:

rüdiger schrieb:

statische Polymorphie ist ja im Grunde nur bei statischem Typing möglich. Statisches Typing verrät eben Eigenschaften über die Absichten und Zukunft. Daher kann ich auch Dinge wissen über Objekte, die noch gar nicht existieren.

Das Problem damit ist halt, dass man, wie du selbst sagst, kein Objekt dafür braucht. Das Ding nennt sich aber Objekt-Orientierung und nicht Klassen-Orientierung und auch nicht Typ-Orientierung. Welchen Sinn hat es etwas objekt-orientiert zu nennen, wenn es etwas ist, was kein Objekt hat und auch nicht benötigt?

Man braucht kein Objekt im Sinne eines Speicher Abbildes.

Ja natürlich. Siehe auch das Post über Erlang. Lass uns mal nachschauen, wie sich das mit deiner Definition verhält:

1. Vererbung: Ja, die existiert zumindest bei Prozessen. Ein neuer Prozess erbt ja die Eigenschaften des Elternprozesses
2. Encapsulation: Ja, die existiert zumindest bei Prozessen/Kernel.
3. Laufzeit Polymorphie: Ja, die existiert. Nachrichten werden erst zur Laufzeit an den Prozess/Kernel dispatcht.
=> Wunderbar OO

Ich weiß doch, dass nach deinem Verständnis so ziemlich alles objekt-orientiert ist.

Nein, das ist es nicht.

Aber verwende dazu doch bitte nicht die OOP-Definition.

_die_? Du meinst Stroustrups?

Vererbung ist schließlich als Mechanismus definiert mit dem aus einer Abstraktion eine neue erzeugt werden kann (sogar ohne die alte ändern zu müssen). Das trifft offensichtlich nicht auf Prozesse zu. Ein laufender Prozess ist keine Abstraktion und dient einem Kindprozess auch nicht als funktionale "Bauvorlage", welche durch das Kind spezialisiert wird.

Natürlich ist ein laufender Prozess eine Abstraktion. Und er dient in dem Sinne dem Kind als Bauvorlage, das beim forken eines neuen Prozesses der alte Prozess kopiert wird. Ob das Kind nun das Verhalten spezifiziert oder was eigenes macht, hängt halt vom Kind ab. Aber wenn wir encapsulation in CLOS auch hinnehmen, wenn man dafür das MOP ändern muss, dann kann man darüber wohl auch hinweg sehen, das ein Kindprozess die Möglichkeit hat nicht die gleichen Nachrichten wie ein Elternprozess anzunehmen.

[minhen]

Mr. N schrieb:

Selbst dann würde ich mich an die Einstellung-und-Ansatz-Definition halten, weil die einfach vernünftig und üblich ist.

Wird ja immer besser. Demnach sind also alle Programmiersprachen objekt-orientiert oder keine. Schließlich ist das, was ich mir denke, nicht von der Programmiersprache abhängig, sondern nur von meiner Phantasie begrenzt. Super Defintion! Dass das nicht vernünftig ist, sollte nun wirklich jedem einleuchten. Und üblich? Ignorieren wir mal, dass es völlig egal ist, wer was glaubt. Außerhalb des Forums wird's bereits eng für dich. Selbst die Wikipedia beeilt sich (besonders auf Englisch) möglichst schnell von Kapselung, Vererbung und Polymorphie zu sprechen. Alan Kay, Bjarne Stroustrup ... alle nicht deiner Meinung. Aber du hast natürlich die übliche "Definition". Ist klar

rüdiger schrieb:

Natürlich ist ein laufender Prozess eine Abstraktion. Und er dient in dem Sinne dem Kind als Bauvorlage, das beim forken eines neuen Prozesses der alte Prozess kopiert wird. Ob das Kind nun das Verhalten spezifiziert oder was eigenes macht, hängt halt vom Kind ab. Aber wenn wir encapsulation in CLOS auch hinnehmen, wenn man dafür das MOP ändern muss, dann kann man darüber wohl auch hinweg sehen, das ein Kindprozess die Möglichkeit hat nicht die gleichen Nachrichten wie ein Elternprozess anzunehmen.

So? Was abstrahiert ein laufender Prozess denn? Ich dachte mir auch schon, dass du mit fork kommst. Deshalb hab ich das eigentlich schon vorweg genommen. Denn ein geforkter Prozess ist eine exakte Kopie, keine abstrakte Bauvorlage, die verfeinert werden kann. Der gesamte Code des Kindes ist bereits im Elternprozess vorhanden. Dazu sagst auch nur du Vererbung.