Performancemythen?

[Gast]

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?

[Gast]

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

[Gast]

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.

[Tellerrand]

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.

[Gast]

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.

[Tellerrand]

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

[rüdiger]

minhen schrieb:

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.

Ist die Frage ob ich in CLOS das kann. Ich kann Member entweder unschreibbar machen _für jeden_ oder ein "böser Nutzer" kann ihn beliebig manipulieren.

Xin schrieb:

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.

Komisch, dass das eine Person sagt, die den ganzen Thread über Beleidigungen und Pöbeleien von sich gegeben hat...

[Asynchronmaschine]

Unglaublich, jetzt schreib doch nicht dauernd von ihm ab!

[virtuell Realisticer]

Shade Of Mine schrieb:

Wenn einem die Argumente ausgehen kommen die Beleidigungen - Schade.

Endet es nicht immer so?

gruss
v R

[DEvent]

Seite 46

Xin schrieb:

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

Obwohl beides schlägt, besteht hier ein guter Grund, kein Interface und damit auch keine Beziehung herzustellen, also damit auch OOP auszuschließen.
Objekt::schlagen() ist einmal lebenserhaltend, konstruktiv und notwendig und einmal lebensgefährlich, destruktiv und überflüssig. Semantisch haben beide schlagen() keine sinnvolle Gemeinsamkeiten.
Das ist sogar ein guter Grund hier keine Templates zu verwenden, obwohl Templates nicht interessiert, ob zwischen "Herz::schlagen()" und "Mensch::schlagen()" eine semantische Beziehung besteht oder nicht.

Selbiges gilt für bool Person::istArm() oder Körperteil::istArm() uvm...
Bei derartigen Dingen ein Interface zu konstruieren, damit man Objekte, die die Schnittstelle "istArm()" implementieren per OOP ansprechen kann, lässt sich nur als Designfehler beschreiben. Somit geht "Man abstrahiere nur richtig und schon passt es" und "Selektive Ignoranz" ungeöffnet an den Absender zurück.

Genau das hat mich eben gestoert und stoert mich an JS. Man kann eben jeden Objekttyp als einen Parameter nehmen und behaupten, das er richtig ist, nur weil er zufaellig die richtigen Methoden anbietet. Das der Typ dann doch falsch ist, merkt man erst viel Speater, nachdem man stunden rumgeraetzelt hat wieso das Programm etwas macht, obwohl es etwas anderes machen muesste.

Durch die Beziehung "ist ein" in der Klassenhierrachie kann ich solche Fehler vermeiden, bzw. gar nicht erst aufkommen lassen. Dies wurde z.B. auch in PHP erkannt, indem man Typen fuer Objekte eingefuehrt hat.

Seite 49:

Shade Of Mine schrieb:

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

Im Asm Code findest du ueberhaupt nichts wieder. Ausser Gotos und bedingten Spruengen. Ist das Konzept von Funktionen dann auch irrelevant?
Hier gibts du Xin aber auch Recht, denn er hat die Behauptung aufgestellt, dass sich die Programme seit den Spruengen im Programm nicht weiter entwickelt haben.

Shade Of Mine schrieb:

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

Nein eben nicht. In JS laesst du die Tatsache fallen das X "ist ein" Y ist. Du kannst in JS fuer X irgendwas einsetzen und behaupten "es ist ein Y", das X muss es aber nicht.

Shade Of Mine schrieb:

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

Genau das sage ich doch die ganze Zeit. Sie sind unsicher und erlauben mehr Dynamik. Ich weis nur nicht wozu diese Dynamik gut sein soll.

Shade Of Mine schrieb:

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

das Beispiel ist aber ziemlich flasch.

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

Woher will denn das der Compiler wissen? Nach deinem Beispiel muesste der Compiler einen Fehler ausgeben: dynamo does not implements energiequelle. Entweder Typsicherheit, dann braucht man Vererbung. Oder eben nicht.

[otze]

@DEvent

class EnergieQuelle{};//leer
struct Batterie:public Energiequelle
{
    public void foo()
    {...
    }
};

template<class T>
class Elektrogerät
{
     BOOST_STATIC_ASSERT(is_derived<T,EnergieQuelle>::value);
     T member;

     public:
         void bar(){ member.foo();}
};

Jetzt gibt es sogar die Absicherung vom programmierer, dass Batterie eine Energiequelle ist, und somit mit dem Interface übereinstimmt. Vererbung ist, wie wir alle sagten, manchmal sinnvoll, aber nicht zwingend.

wenn ich einen int ähnlichen Objekttyp brauche, werde ich sicher nicht danach schauen, ob es von "Int" abgeleitet ist. mir reicht es, wenn alle Operatoren überladen sind, die ein Int braucht. Was sich wie ein int verhällt, ist ein int.

[@Xin]

komisch in smalltalk ist der typ eines objekts auch ein objekt. und jetzt? gilt deine definition jetzt nur für maschinenkompilierte sprachen? hm moment es gibt auch compiler die aus smalltalk maschinencode generieren
wen interessiert überhaupt maschinencode?
ist ood nicht ein paar ebenen weiter höher?

[minhen]

virtuell Realisticer schrieb:

Shade Of Mine schrieb:

Wenn einem die Argumente ausgehen kommen die Beleidigungen - Schade.

Endet es nicht immer so?

gruss
v R

Wobei der besondere Witz der ist, dass das hier gar nicht der Fall ist. Denn der, der beleidigt hat, ist interessanterweise gar nicht der, dem die Argumente ausgegangen sind. Das sollte einem schon zu denken geben.

Interessant ist auch, dass hier "Ruhe" herrschte während rüdiger und ich diskutiert haben. Und die einzigen offenen Punkte sind jetzt noch, ob Prozesse Objekte sind (was eine nette Seitendiskussion hätte werden können), sowie wie Kapselung in Lisp umgesetzt ist. Damit ist Stroustrups Definition als solche also endügltig geklärt. Aber sobald ich das Thema auf die schwammige, mystische und irgendwie esoterische Definition lenkte, um eben über diese ebenso zu reden, geht's hier rund. Und plötzlich melden sich all jene zurück, die sich bei der ernsthaften Diskussion herausgehalten haben. Wozu das jetzt führt, sieht man ja. Eine interessante Beobachtung ist es dennoch.
Besonders die letzten Äußerungen von Shade of Mine und Mr. N sind da besonders schön. Auch nett ist, wie längst geklärte Sachen wieder ausgegraben werden. Aber dann wiederum ist das nichts neues. Schließlich hat der Thread hier ja nicht wegen vorgebrachten Argumenten und einer vernünftigen Diskussion stolze 55 Seiten erreicht ...

[Undertaker]

minhen schrieb:

Und die einzigen offenen Punkte sind jetzt noch, ob Prozesse Objekte sind (was eine nette Seitendiskussion hätte werden können)

es könnten welche sein.
sie erfüllen ja einige kriterien, die allgemein für objekte gelten. sie können untereinander nachrichten austauschen, sie verstecken ihr innenleben (datenkapselung), sie können auf input dynamisch und unterschiedlich reagieren (polymorphismus). den programmcode eines prozesses könnte man als 'klasse' bezeichnen... usw.