Performancemythen?

Mr. N

minhen schrieb:

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

Immerhin habe ich versucht, mit dir (jetzt da Xin weg ist) vernünftig zu diskutieren. Offensichtlich willst du das aber gar nicht.

minhen

Mr. N schrieb:

Immerhin habe ich versucht, mit dir (jetzt da Xin weg ist) vernünftig zu diskutieren. Offensichtlich willst du das aber gar nicht.

Also das ist wirklich ein schlechter Witz. Traurig ist nur, dass du vermutlich selbst daran glaubst. Aber dann schau mal meinen Beitrag und deine Antwort an. Und jetzt zeig mal wo du da diskutierst.

Mr. N hat im Gegensatz zu euch anderen wenigstens Argumente gebracht.
Die konntet ihr nicht zerschlagen, ergo hat er Recht.

rüdiger

Doktor Prokt schrieb:

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.

Durch das ändern des MOPs kann man alles erreichen. Klar, wenn man das zählt, kann man auch Slot-Elemente verstecken. Wie man dann privat drauf zugreift kann ich mir gerade noch nicht vorstellen. Aber klar, auch das sollte möglich sein.

minhen schrieb:

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.

was ein laufender Prozess abstrahiert hängt wohl von dem Prozess ab. Gegenfrage: Was kann ein Objekt abstrahieren, was ein Prozess nicht abstrahieren kann?

Du kannst ohne Probleme Code nachladen, wenn du das willst. Du kannst deine Kopie ja beliebig ändern. Entspricht halt eher der Vererbung die JS anbietet, als der die C++ anbietet.

Xin

minhen schrieb:

Mr. N schrieb:

Immerhin habe ich versucht, mit dir (jetzt da Xin weg ist) vernünftig zu diskutieren. Offensichtlich willst du das aber gar nicht.

Also das ist wirklich ein schlechter Witz.

Hier muss ich Dir allerdings mal widersprechen, minhen.

Ich finde "Denke ich nicht" als Argument in der Tat sehr amüsant. Ich würde das als Foren-Slapstick einordnen. Komisch - wenn auch vollkommen unbeabsichtigt. Sehr schön auch die nachträgliche Pointe, das ganze als "vernünftig" zu bezeichnen. Und im Fach der Foren-Slapstick haben sich hier einige Experten vor uns aufgetan.

Dass ich das inzwischen komisch finde, mag allerdings auch daran liegen, dass ich nicht mehr versuche zu überzeugen, sondern nur noch Kindern beim Spielen im diesem Kindergarten zusehe. Das mag Erwachsenen nicht sinnvoll erscheinen, hat aber durchaus etwas niedliches.

Minhen... Du kannst das problemlos mit den Kiddies hier noch 30 Seiten fortführen - vertrau mir, ich weiß, wovon ich spreche. Naja, die ersten 10 oder 15 hast Du ja auch schon locker.
Kinder werden nicht über Nacht erwachsen, das müssen wir beide einsehen. Und das ist auch das, was ich aus diesem Thread mitnehmen kann.
Also lehn Dich zurück, genieße die Sonne und pass auf, das keins der Kleinen über den Zaun klettert und in einem Deiner Projekte landet.

@minhem.
Ich glaube da hab ich etwas misverständlich formuliert.
Mir ging es nicht um die Präzision mit der man eine Menge definiert, sondern um die Teile der Menge, präzise sollten sie immer sein.

Das was ich eigentlich aussagen wollte war, das sich eine Definition nicht an der Menge messen lässt welche sie eingrenzt, es sei denn man hat eine feststehende Menge.
Wenn ich einen Zahlenraum definiere und ihn die Tellerrandschen Mengen nenne, dann spielt es keine Rolle ob die 0 nun drin ist, solange die Definition stimmig ist.

Insbesondere beim Thema OO steht die Menge der OO Sprachen nicht fest, sondern es existiert viel eher eine Menge von Teilen aus verschiedenen Sprachen welche man als OO ansehen kann.

Von daher halte ich es für unklug eine Definition OO daran zu bewerten welche Sprachen sie nun umfast.
(War ja auch nicht explizit dich gerichtet, sondern eher an die Allgemeinheit.
Irgendwie lief die Diskussion in die Richtung, zumindest hatte ich das Gefühl es wäre so.)

@Xin, ich brauchte heute Morgen ein Beispiel für die subtile histrionisierung der Menschheit, dafür war das danke.
Ich lege dir, durch eine einfache Frage, den Ball vor und du traust dich nicht ihn zu versenken ... schade eigentlich.

Shade Of Mine

Wenn einem die Argumente ausgehen kommen die Beleidigungen - Schade.

Xin

Tellerrand schrieb:

@Xin, ich brauchte heute Morgen ein Beispiel für die subtile histrionisierung der Menschheit, dafür war das danke.

Liebelein, wenn Du mich schon beleidigen willst, dann wird mir die unterschwellige Schauspielerei doch bitte auf Deutsch vor. Für eine Beleidigung ist das übrigens recht mager. Wenn Du mich in die Hysterie (histrionische Persönlichkeitsstörung) treiben möchtest, solltest Du an Deinen Beleidigungen noch etwas arbeiten.

Um das Niveau Deiner Beleidigungen drastisch zu erhöhen, empfehle ich Dir zum Einstieg Monkey Island Teil 1.
Wenn Du die Prüfung im Beleidigen schaffst, bekommst Du sogar ein T-Shirt. Also... tschakaa!

Tellerrand schrieb:

Ich lege dir, durch eine einfache Frage, den Ball vor und du traust dich nicht ihn zu versenken ... schade eigentlich.

Sorry, ich mag kein Fussball, ich spiele Volleyball.
Abgesehen davon ist es nicht nötig bei Dir noch irgendwas zu versenken.

tellerrand schrieb:

Xin schrieb:

Meine Definition von Objekt ist alles außer void.

Warum sollte der Objekttyp kein Objekt sein? [...]

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

Graben wir doch noch mal 2+2=4 aus. Wie tief muss man sinken, wenn man eine Frage stellt "Wieviel ist 2+2, Deine Antwort "zwei plus zwei ist vier" beantwortet die Frage einfach nicht!".
Jetzt mal ehrlich, muss ich da wirklich nochmal nachtreten, um irgendwas zu versenken?

rüdiger schrieb:

Durch das ändern des MOPs kann man alles erreichen. Klar, wenn man das zählt, kann man auch Slot-Elemente verstecken. Wie man dann privat drauf zugreift kann ich mir gerade noch nicht vorstellen. Aber klar, auch das sollte möglich sein.

Man kann slot-value-using-class im MOP mit einer :around-Methode ueberschreiben (die wird dann immer aufgerufen, wenn jmd. einen Slot ueber (setf (slot-value obj name) val) versucht zu setzen.
Ruft man darin (in der ueberschriebenen slot-value-using-class) call-next-method auf, wird die urspruengliche slot-value-using-class aufgerufen und der Slot tatsaechlich gesetzt. Ansonsten behaelt der Slot seinen alten Wert oder bleibt ggf. ungebunden.

Ja, es ist etwas haesslich, funktioniert aber.

rüdiger

@Doktor Prokt
Ja, aber wie führt man dann in einer Methode eine Änderung durch?

Vllt. noch ein Beispiel dazu:
Hier wird der Slot x nur gesetzt, wenn x > 0 ist:

(defclass a () (x))

(defmethod (setf sb-mop:slot-value-using-class) :around
    (new-value (class standard-class) (object a) slotd)
  (when (> x 0)
    (call-next-method)))

in Aktion:

CL-USER> (defparameter foo (make-instance 'a))
FOO
CL-USER> (slot-value foo 'x)
1
CL-USER> (setf (slot-value foo 'x) -4)
NIL
CL-USER> (slot-value foo 'x)
1
CL-USER> (setf (slot-value foo 'x) 8)
8

rüdiger schrieb:

@Doktor Prokt
Ja, aber wie führt man dann in einer Methode eine Änderung durch?

Das geht schlecht, weil eine Methode nicht zu einer Klasse gehoert. CLOS hat multiple-dispatch und keinen single-dispatch.

rüdiger

Doktor Prokt schrieb:

rüdiger schrieb:

@Doktor Prokt
Ja, aber wie führt man dann in einer Methode eine Änderung durch?

Das geht schlecht, weil eine Methode nicht zu einer Klasse gehoert. CLOS hat multiple-dispatch und keinen single-dispatch.

Ich bin mir nicht sicher wie Stroustrup genau encapsulation definiert. Aber ich zweifel mal, dass er damit meint, das man ein Member komplett vor Veränderung schützt. Er bezieht das auf die Abstufung, was darf ein public-Zugriff, was ein private-Zugriff und was ein protected-Zugriff.

Ok, ich entschuldige mich dafür, das war wirklich unterste Schublade.

Mal zurück zum Diskussionspunkt.
Die Klasse type_info hat nichts mit der Fragestellung zu tun.
Diese Klasse liefert nur Instanzen welche die Typen beschreiben, kann man auch direkt am Klassennamen ablesen.
Ich habe jedoch eine andere Frage gestellt.

Nochmal anderst formuliert, etwas Pseudo Code
ClassOfA a := new ClassOfA;
ClassOfA.funktion;
a.funktion;
Ist "ClassOfA" ein Objekt?
(Und dann halt noch die anderen gestellten Fragen)

@Shade Of Mine:
Mir ist eine einfache Beleidigung weitaus lieber als dieses "Ich rede mal lieber drumherum und stichel wo und wann es nur geht, anstatt klar und einfach zu antworten"
Da lag das Wort histrionisch auf der Zunge und man verschwendet nicht so viel Text und Zeit.

Apollon

rüdiger schrieb:

Doktor Prokt schrieb:

rüdiger schrieb:

@Doktor Prokt
Ja, aber wie führt man dann in einer Methode eine Änderung durch?

Das geht schlecht, weil eine Methode nicht zu einer Klasse gehoert. CLOS hat multiple-dispatch und keinen single-dispatch.

Ich bin mir nicht sicher wie Stroustrup genau encapsulation definiert. Aber ich zweifel mal, dass er damit meint, das man ein Member komplett vor Veränderung schützt. Er bezieht das auf die Abstufung, was darf ein public-Zugriff, was ein private-Zugriff und was ein protected-Zugriff.

Die Erklaerung auf Wikipedia ist auch nicht das was ich unter Kapselung verstehe, daher habe ich sie bei der Definition von DEvent aussen vor gelassen. IMO ist aber Kapselung aus OOP nicht wegdenkbar. Ist also ein wesentliches Merkmal.

rüdiger schrieb:

Doktor Prokt schrieb:

rüdiger schrieb:

@Doktor Prokt
Ja, aber wie führt man dann in einer Methode eine Änderung durch?

Das geht schlecht, weil eine Methode nicht zu einer Klasse gehoert. CLOS hat multiple-dispatch und keinen single-dispatch.

Er bezieht das auf die Abstufung, was darf ein public-Zugriff, was ein private-Zugriff und was ein protected-Zugriff.

Dann, befuerchte ich, hat er CLOS nicht verstanden.

otze

@tellerrand guter versuch, hab ich auch probiert.

leider kommt dann als antwort: keine ahnung, ich hab nicht genug informationen um das zu entscheiden(was mich zum endgültigen Schluss brachte, dass xins definition absolut unbrauchbar ist).

minhen

Doktor Prokt schrieb:

rüdiger schrieb:

Er bezieht das auf die Abstufung, was darf ein public-Zugriff, was ein private-Zugriff und was ein protected-Zugriff.

Dann, befuerchte ich, hat er CLOS nicht verstanden.

Keine Angst, Stroustrup hat sowas natürlich nie von CLOS behauptet. Was er dagegen allgemein sagt ist:

[1] Abstraction - the ability to represent concepts
    directly in a program and hide incidental
    details behind well-defined interfaces (...)

[2] Encapsulation - the ability to provide guaran-
    tees that an abstraction is used only according
    to its specification (...)

Kein Wort von Abstufungen, public, private oder protected.

@otze
Er hat ja schon oft genug geschrieben "Meine Definition von Objekt ist alles außer void.", ich warte da nur auf eine endgültige Bestätigung, dass eine Klasse, nicht void, ein Objekt ist.

Irgendwie verhaut das nämlich einiges seiner Definition, oder zumindest müsste man nochmal einige Punkte überdenken, bzw. stellen sich mir dann neue Fragen.

Xin

Tellerrand schrieb:

Ok, ich entschuldige mich dafür, das war wirklich unterste Schublade.

Der optimale Satz, um nach den Postings ein *plonk* zu verhindern. Die Erkenntnis kommt spät, aber dennoch kann ich gratulieren: Du bist der Erste.
Wenn sich dieser Nebel bei Dir auflösen kann, hat es vielleicht ja doch noch Sinn, Dir Fragen zu beantworten.
Finden wir es heraus.

Tellerrand schrieb:

Die Klasse type_info hat nichts mit der Fragestellung zu tun.
Diese Klasse liefert nur Instanzen welche die Typen beschreiben, kann man auch direkt am Klassennamen ablesen.

Du kannst zur Laufzeit keine Klassennamen ablesen oder sonstige Informationen eines beliebigen Datentyps erhalten. Du musst ein Objekt fragen, wie der Klassenname lautet. In C++ hat ein Objekt, das einen Datentyp beschreibt, selbst den Datentyp "type_info".

Ob Objekttypen Objekte sind war Deine Frage. Objekttypen sind Datentypen von Objekten. Ich nenne Dir den Namen der Klasse, deren Objekte Datentypen beschreibt. Das ist meine Antwort und das Weiterdenken überließ ich Dir.

Hier also die "Extended Version":
Datentyp-Beschreibungen sind Objekte. Der semantische Unterschied zwischen Datentyp und Datentypbeschreibung ist hoffentlich klar, die 1:1 Beziehung aber hoffentlich ebenso. Die Datentypbeschreibung ist damit eine eindeutige Identifizierung des Datentyps. Damit hast Du ein Objekt, dass genau einem Datentyp zuzuordnen ist.

Von einem Datentyp selbst bleibt nach dem Kompilieren nur noch die Typ-Beschreibung eben dieses über. Der Datentyp selbst wird durch das Kompilieren genauso verwurstet, wie z.B. die Signatur einer Funktion.

Tellerrand schrieb:

Ich habe jedoch eine andere Frage gestellt.

Nochmal anderst formuliert, etwas Pseudo Code
ClassOfA a := new ClassOfA;
ClassOfA.funktion;
a.funktion;
Ist "ClassOfA" ein Objekt?

Also nochmal für den Beispielcode: ClassOfA ist eine Klasse, also ein Datentyp und kein Objekt. Wenn Du zur Laufzeit Fragen kannst, was es für ein Datentyp ist, muss ein Objekt vorhanden sein, dass den Datentyp beschreiben kann.

Datentypen existieren zur (nativen) Laufzeit nicht mehr in der abstrakten Form, wie Klassen oder Strukturen im Sourcecode, sondern sind lediglich ein Array von Bytes. Zur Laufzeit existieren lediglich die Grundtypen über, die die Maschine verarbeiten kann. Das sind byte, word, doubleword auf 32Bit Systemen. Hat das System eine FPU kommen noch float und double hinzu. Moderne CPUs haben häufig noch besondere Erweiterungen. So kann der PowerPC ganze Strings (Byte-Arrays) im Prozessorkern verarbeiten. Abstrakte Datentypen, wie es Strukturen darstellen, können von einer CPU allerdings nicht "verstanden" werden.

Das gilt für alle nativ kompilierenden Sprachen. Für Interpreter (JS, PHP, ...) muss das logischerweise nicht zutreffen. Für kompilierende Sprachen, die interpretiert ausgeführt werden (Perl, Java) muss das genausowenig zutreffen.
Hier ist es möglich, dem Interpreterkern den Datentyp verständlich zu machen, was vorrangig bedeutet, dass der Interpreter mit angezogener Handbremse läuft, weil deutlich mehr Daten verarbeitet werden müssen. Der Vorteil ist natürlich, dass man mehr Informationen zur Laufzeit hat und man bei manchen Sprachen auch den Datentyp zur Laufzeit modifizieren kann, wie z.B. bei JS.

Tellerrand schrieb:

(Und dann halt noch die anderen gestellten Fragen)

Erstens: Hier wiederholen sich die meisten Fragen, wenn sie schon beantwortet ist, bin ich weder bereit noch gewillt Dir die Antworten rauszusuchen.
Zweitens: Hier stehen viele Fragen - ich bin weder bereit noch gewillt Dir Deine Fragen rauszusuchen.

Wenn Du weiterhin (unbeantwortete) Fragen stellen möchtest, so stelle sie auch.

Nochmals zur Erinnerung: ich bin aus dem Thread soweit raus, ich sehe mich nicht mehr moralisch verpflichtet hier irgendwelche Fragen zu beantworten. Das ist meine Zeit, die hier für Deine Erleuchtung drauf geht. Ich guck mir das Schauspiel hier als Zuschauer an und amüsiere mich über Postings, die dem gesunden Menschenverstand widersprechen.
Der einzige Grund, Dir und Deinen Fragen noch irgendeine Beachtung zu schenken, ist die Erleuchtung, die Du im ersten Satz Deines Postings hattest.
Das mag arrogant klingen, findet seinen Ursprung aber nicht in der Arroganz, sondern dass in der Überzeugung, alle (sinnvollen) Fragen beantwortet und erklärt zu haben. Nach den ganzen Beleidigungen im Thread und im IRC erscheint es mir auch nicht notwendig, noch irgendeine Form von Zuvorkommen zu zeigen.

Also... stelle Deine (hoffentlich sinnvolle) Fragen und Du erhältst (hoffentlich sinnvolle) Antworten.

Tellerrand schrieb:

@Shade Of Mine:
Mir ist eine einfache Beleidigung weitaus lieber als dieses "Ich rede mal lieber drumherum und stichel wo und wann es nur geht, anstatt klar und einfach zu antworten"

Wenn Du in die Frage die Antwort packst, und dazu schreibst, dass es nicht die Antwort ist, dann kannst Du eigentlich nur Ironie erwarten oder wirst direkt für dumm erklärt. Ich finde meine leicht zynische Art bei der Frage als ausgesprochen höflich. Deinen Geisteszustand in Frage zu stellen, hätte bei der Frage durchaus im Rahmen der logisch nachvollziehbaren Rückfragen gestanden, ohne unhöflich zu sein.

Tellerrand schrieb:

Da lag das Wort histrionisch auf der Zunge und man verschwendet nicht so viel Text und Zeit.

Für eine gut gemachte Beleidigung hättest Du mehr Zeit ver[sch]wenden sollen.

Edit:

Tellerrand schrieb:

@otze
Er hat ja schon oft genug geschrieben "Meine Definition von Objekt ist alles außer void.", ich warte da nur auf eine endgültige Bestätigung, dass eine Klasse, nicht void, ein Objekt ist.

Darauf willst Du also hinaus... hier nochmal die Kurzform:

void bezieht sich auf den Datentyp des "Objektes". Das ist vielleicht nicht 100% eindeutig mit 'Ein Objekt ist alles außer void.' ausgesagt, aber minhen hat es verstanden und ich ging eigentlich davon aus, dass es eindeutig verständlich ist.

Also einmal klarer ausformulieren:
Ein Objekt ist eine Instanz eines beliebigen Datentyps, sofern der Datentyp nicht void ist.

Eine Klasse ist ein Datentyp. Eine Instanz einer Klasse ist ein Objekt, dessen Datentyp der Klasse entspricht - also nicht void.

void a;

a ist vom Datentyp void. a ist nichts. a ist kein Objekt.

Eine Instanz mit virtuellen Funktionen hat einen Zeiger auf eine VTable. Das ist ein Objekt, dass ebenfalls ein Objekt vom Datentyp type_info enthält oder referenziert. Eine Klasse ohne virtual ist nicht OOP, hier kann die Referenz auf die type_info-Instanz ebenfalls statisch ablaufen.