Typen in Objektsystemen / Laufzeit

DEvent

^mngbd schrieb:

Ich denke dann daran, daß wohl jedes Objekt im Speicher ein paar Bits haben wird, aus denen sich der Typ ergibt, und die müsste man nur herausbekommen und als Index in ein Array verwenden, um das gleiche ich konstanter Zeit zu machen.
Nur will ich auf diese Bits nicht zugreifen, wenn's auch anders geht.
Geht's auch anders? Ich hoffe, dass ihr mir das sagen könnt...

Wie soll den das gehen, die Typen aller Sprachen der Welt musst du dann mit diesem "bit" immer noch vergleichen. Dazu kommt das die Typen in allen Sprachen unterschiedlich implementiert sein koennten. Du denkst an eine Art von Array wenn du an Listen denkst, aber man kann Listen auf 1000und1 Methode implementieren, z.B. als verkettete Listen, als Hash-Maps, als Baeume usw. usf. Das gleiche fuer Strings, man kann sie als ein statisches Array, oder als eine verkettete Liste implementieren. Du musst da schon auf Typ ueberpruefen und dann dessen Methoden aufrufen, oder du nutzt die Moeglichkeit der Sprache (wie z.B. len() in Python).

~john schrieb:

Denn was Du beschrieben hast, ist manuelles Dispatching auf Basis der Typinformation.

Hab mir ja gedacht, dass es da einen tollen Fachausdruck gibt.

~john schrieb:

Aber genau dazu existiert Polymorphie.

Den Eindruck hatte ich auch...
Aber manchmal muss man's eben selbst bauen.

DEvent schrieb:

Wie soll den das gehen, die Typen aller Sprachen der Welt musst du dann mit diesem "bit" immer noch vergleichen.

Sorry, da war ich unklar. Mir geht's immer nur um eine Sprache, und da kommt immer nur eine Hand voll Datentypen in Frage.
Ist aber auch egal: eigentlich wollte ich nur sagen, dass man's auch besser machen kann, wenn man auf die Interpreter-internen Dinge zugreift.
Aber dann läuft das ganze eben nur mehr auf diesem Interpreter.

DEvent schrieb:

Du musst da schon auf Typ ueberpruefen und dann dessen Methoden aufrufen, oder du nutzt die Moeglichkeit der Sprache (wie z.B. len() in Python).

Ich gehe aber davon aus, dass meine Sprache gar keine Moeglichkeiten für sowas hat, ich also selbst den Typ prüfen muss.

Beispiel in Scheme:
Da gibt es zum Prüfen der Typen die Funktionen string? und pair? , die nachsehen, ob etwas ein String oder eine Liste ist. Sonst nichts.
Nun wäre es aber einfach schneller, wenn ich statt vieler Funktionen eine einzige habe, die mir den Typ zurückgibt, also vielleicht die Zahlen TYPE_STRING oder TYPE_LIST; diese Rückgabewerte könnte ich dann als Sprungindex verwenden.

Weil ich aber axiomatisch nicht glaube, dass ich die Sprache besser verstehe als andere, gehe ich davon aus, dass ich da was übersehen habe, was mir das Leben leichter machen würde.

man kann auch versuchen, die Klassenhierarchie so fein abzustufen, daß "Typ-Weichen" zur Laufzeit vermieden werden. Zum einen kann String Unterklasse von List sein, Problem gelöst durch Vererbung.

Andernfalls kann man eine gemeinsame Oberklasse, etwa "Sequencable", von String und List konstruieren; dann wird len 1-mal in Sequencable implementiert, String + List erben diese Methode.

volkard

u_ser-l schrieb:

man kann auch versuchen, die Klassenhierarchie so fein abzustufen, daß "Typ-Weichen" zur Laufzeit vermieden werden. Zum einen kann String Unterklasse von List sein, Problem gelöst durch Vererbung.

Das würde aber ausdrücken, daß der String eine List sei. Ob man das ausdrücken möchte, sollte bitte nicht allein durch die die pure Faulheit bestimmt sein.

byto

Bei einem eigenen Objektmodell definiert man sich z.B. ein Interface LengthAware mit einer Methode length() und die Sache ist gegessen. Alle Objekte mit einer Länge implementieren das Interface.

Funktioniert halt nicht, wenn man mit Third Party Klassen arbeitet, die das Interface nicht verwenden. Dafür könnte man sich Adapter schreiben.

knivil

ZB für Scheme kursiert ein Objektsystem "Meroonet"

Da gibt es recht viele und jeder Lisp/Scheme-Programmierer hat wohl schon sein eigenes geschrieben. Dennoch koennen Listen in Scheme nur in O(n) getestet werden, Strings in O(1).

Das würde aber ausdrücken, daß der String eine List sei. Ob man das ausdrücken möchte, sollte bitte nicht allein durch die die pure Faulheit bestimmt sein.

In Haskell ist es glaube so.

Bei einem eigenen Objektmodell definiert man sich z.B. ein Interface LengthAware mit einer Methode length() und die Sache ist gegessen. Alle Objekte mit einer Länge implementieren das Interface.

Koennt ihr auch noch anders als objektorientiert denken ... ist ja schlimm. Man nimmt die Mittel, die da sind. Was wuerdet ihr machen, wenn die Sprache eurer Wahl(Zwang) kein natives Objektsystem hat mit dem ganzen Schnickschnal wie Vererbung oder Interfaces?

wenn man auf die Interpreter-internen Dinge zugreift

In Scheme sind null?, pair?, number? oder string? das Interface zu den interpreterinternen Sachen und lesen die Typinformation der (cons)Zelle aus. Sind also O(1). Bei list? geht das nicht und liegt am Aufbau von Listen in Scheme.

u_ser-l schrieb:

man kann auch versuchen, die Klassenhierarchie so fein abzustufen, daß "Typ-Weichen" zur Laufzeit vermieden werden. Zum einen kann String Unterklasse von List sein, Problem gelöst durch Vererbung.

Klingt sauber. Ich denk mal darüber nach, wie sehr die vielen Zeiger auf dem Weg bis zur Basisklasse in der Performance ins Gewicht fallen.
Wahrscheinlich nicht sehr, weil ich ohnehin mit Zeigern arbeiten will.

Und ja, natürlich mit abstrakter Basisklasse, denn

volkard schrieb:

Öffentliche Vererbung bedeutet "ist ein".

Da war doch mal die Geschichte mit dem Mann, der ein Atuo vom Motor ableitet (oder so ähnlich).
Das ist sogar bei mir hängen geblieben, obwohl ich eher OOP-Muffel bin.

byto schrieb:

Alle Objekte mit einer Länge implementieren das Interface.

Aber da habe ich ein Problem mit den eingebauten Typen.
Wenn Typ eine Eigenschaft der Objekte im System ist, das ich gerade erfinde, dann haben die eingebauten Typen wie Strings oder Zahlen keinen solchen Typ.
Also auch kein Interface, an das ich mich halten könnte.

knivil schrieb:

Da gibt es recht viele und jeder Lisp/Scheme-Programmierer hat wohl schon sein eigenes geschrieben.

Habe die Zahl um eins erhöht...

knivil schrieb:

In Scheme sind null?, pair?, number? oder string? das Interface zu den interpreterinternen Sachen und lesen die Typinformation der (cons)Zelle aus. Sind also O(1).

Damit habe ich aber schon: string?, vector?, table?, und u.U. diverse Fix-Array-Typen.
Da kann schon eine cond-Kette mit 8 oder 10 Abfragen herauskommen, und davon müssen einfach durchschnittlich 4 oder 5 gemacht werden.
Bei einer ref-Funktion ist das vielleicht schon teurer als der ganze Rest.

Jedenfalls studiere ich gerade den src-Ordner meines Scheme-Interpreters.
Wär doch gelacht, wenn ich das nicht selbst hinkriegen würde...

byto

knivil schrieb:

Bei einem eigenen Objektmodell definiert man sich z.B. ein Interface LengthAware mit einer Methode length() und die Sache ist gegessen. Alle Objekte mit einer Länge implementieren das Interface.

Koennt ihr auch noch anders als objektorientiert denken ... ist ja schlimm. Man nimmt die Mittel, die da sind. Was wuerdet ihr machen, wenn die Sprache eurer Wahl(Zwang) kein natives Objektsystem hat mit dem ganzen Schnickschnal wie Vererbung oder Interfaces?

Wenn die Sprache kein natives Objektsystem hätte, dann würde die Frage des TEs keinen Sinn ergeben. Denn dann würde es auch keine "instanceof" Prüfung geben usw.

Also warum beruhigst Du Dich nicht einfach wieder?

byto schrieb:

knivil schrieb:

Koennt ihr auch noch anders als objektorientiert denken ... ist ja schlimm. Man nimmt die Mittel, die da sind. Was wuerdet ihr machen, wenn die Sprache eurer Wahl(Zwang) kein natives Objektsystem hat mit dem ganzen Schnickschnal wie Vererbung oder Interfaces?

Wenn die Sprache kein natives Objektsystem hätte, dann würde die Frage des TEs keinen Sinn ergeben. Denn dann würde es auch keine "instanceof" Prüfung geben usw.

Also warum beruhigst Du Dich nicht einfach wieder?

Das war ein wenig schroff von knivil, aber irgendwie hat er recht.
Von dem, was du ein natives Objektsystem nennst, hat Scheme wirklich nur einen Teil (wenn ich das alles recht verstanden habe).
Es geht aber letztlich um eine Effizienzfrage -- dass es in jedem Fall möglich ist, sowas selbst zu bauen, ist mir schon klar.

*john 0

knivil schrieb:

Koennt ihr auch noch anders als objektorientiert denken ...

Es wurde explizit nach einer OOP-Lösung gefragt.

Es wurde explizit nach einer OOP-Lösung gefragt.

Stimmt, und ich bin für jede Anwort sehr dankbar, wenn sie mir was zum Nachdenken gibt.

Es ist halt so, dass mein OOP nicht dein OOP ist, und beide nicht fricky's OOP, weil der Begriff viele Schattierungen hat. Deshalb poste ich solche Fragen auch gerne dort, wo sie Jünger mehrerer Sprachen lesen.

*john 0

Der beste Weg ist es, die Klassen gleich richtig in die Klassenhierachie einzufügen. Geht das nicht, dann ist der OOP-Weg der der Wrapperklassen.