Typen in Objektsystemen / Laufzeit
-
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.
-
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.
-
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.
-
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...
-
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.
-
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.
-
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.