zonk: Typecasting und Prototypen von Objekten

Beitrag lesen

Hallo Mathias,

Sehe ich das richtig, primitive Werte haben interne Funktionen, Objekte hingegen Methoden?

Die Frage verstehe ich nicht.

Wie es nicht gemeint war: Funktionen sind ja nutzerseitig nichts anderes als Objekte. Was ich meinte: Methoden = interner JS-Code (oder auch in der eigentlichen Quelltextsprache), der an Objekte gebunden ist und den man überschreiben kann. Funktionen = Code, der in der Sprache, in welcher JS geschrieben ist (welche ist das überhaupt?) ausgeführt wird, also der eigentlich Interpreterkern.

Wie ist es bei Eigenschaften?

Z.B.

a = ["Ein", "Array"];
L = a.length;

Ist length wirklich eine Eigenschaft von a (auf die man nur bei for-in keinen Zugriff hat)?

Ja, klar.

»»

Ganz sicher? Es könnte ja auch einen globalen Speicherbereich geben, der vom Interpreter verwaltet wird, wo alle length-Eigenschaften aller Arrays in einer selbst array- oder objektartigen Struktur bzw. tatsächlich als Array oder Objekt, aber in der eigentlichen Sprache, in der der Interpreter geschrieben ist, liegen.

Und wenn length tatsächlich eine Eigenschaft von a ist, so muß sie besonders geschützt sein. Man kann sie ja zum Beipiel nicht mit einem String überschreiben. Wie wäre dieser Schutz aufgebaut? Eine internes Objekt, in der alle geschützten Eigenschaften und Methoden aufgelistet sind?

Was mich interessiert ist das Handling solcher interner oder vorimplentierter Eigenschaften und Methoden, dazu findet man im Web aber kaum was.

Was sind lokale Variablen oder das Array arguments bei Funktionen?

Lokale Variablen hängen an einem internen »lokale Variablen«-Objekt, auf das man aber nicht direkt zugreifen kann. arguments ist eine solche »lokale Variable«.

Ein Objekt für alle Funktionen? Sind die lokalen Variablen dann nur temporär (persistente Eigenschaften würden den Speicher zumüllen).

Die Frage ist überhaupt, wozu es die Objekte String, Number, Function und Boolean geben muß, noch dazu wenn sich deren Handling von den primitiven Datentypen unterscheidet!

Mein Standardspruch: Objekte haben Identität, Primitives keine.
Objekte sind nur mit sich selbst identisch und somit unvergleichbar (Objekt == AnderesObjekt ergibt immer false, Objekt1 === Objekt2 sowieso). Das Objekt wird behandelt, als ob sein Wert komplex wäre. Bei der Übergabe an Funktionen werden sie deshalb nicht einfach kopiert, sondern immer als Referenz übergeben.
Dieses Verhalten *kann* erwünscht sein, daher kann man Strings und Numbers auch als Objekte anlegen. Außerdem ist die Unterscheidung Primitives vs. Objects bei String, Number und Boolean auch nötig, um intern die prototypische Vererbung und andere Features umzusetzen. Ein Primitive verhält sich ja in vielen Kontexten wie ein Objekt.

Richtig, aber in anderen Sprachen bedarf es dazu nicht solch verwirrender Unterscheidungen und "doppelter" Datentypen. In PHP werden seit Version 5 Objekte standardmäßig als Referenzen übergeben. Will man by value kopieren, gibt es spezielle Befehle. Umgekehrt kann man einfache Datentypen, die standardmäßig als Wert kopiert, verglichen oder übergeben werden, durch Voranstellen von & per Referenz kopieren usw.

Diese Implementierung finde ich intuitiver. Deswegen denke ich, "doppelte" Datentypen sind eigentlich nicht nötig.

Noch mal zur Frage, welchen Status lokale Variablen haben. Sind es (statische oder temporäre) Eigenschaften des Funktionsobjekts zu denen man nur während der Ausführung Zugriff hat (und dann auch nicht über die Objektoperatoren . und []),

Nein. Globale Variablen sind window-Eigenschaften, lokale sind Eigenschaften eines internen Objektes.

»»

Ja, aber früher konnte man ja über funktionsname.lokaleVariable auf sie zugreifen. Ich glaube mit arguments geht das immer noch. Ich nehme an, dann verweist funktionsname.arguments auf das Array arguments in dem internen Objekt. Und bei length muß über funktionsname.length zugegriffen werden (also ist das wahrscheinlich keine Eigenschaft des internen Objektes, sondern eine geschützte Eigenschaft der Funktion).