Performancemythen?

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.

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.

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.