zonk: Typecasting und Prototypen von Objekten

Beitrag lesen

Hallo Tim,

alert() ruft (vermutlich) die interne Methode ToString auf. Für das Number-Objekt ruft diese die interne Methode ToPrimitive mit dem Hint String auf was irgendwann dann in einem Aufruf Deiner toString-Methode landet.

alert(z2);  // ist 10

Für einen Wert vom Typ number hingegen wird aus der internen Funktion ToString die interne Routine zum Umwandeln von Zahlen in Strings aufgerufen, spezifiziert als ToString Applied to the Number Type. An keiner Stelle wird dieser Number-Wert in ein Number-Objekt umgewandelt, dessen toString-Methode genutzt werden könnte.

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

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)? Was sind lokale Variablen oder das Array arguments bei Funktionen?

Manchmal glaube ich, diese Trennung zwischen primitiven Werten und Objekten richtet mehr Schaden an, als sie gutes tut.

Es ist auf jeden Fall verwirrend. 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! Ok, bei Funktionen kann man mit Phantasie noch einen Zweck in dynamisch generierten Funktionen sehen.

f1 = new Function("");
function f2(){}

Functions sind immer Objekte, egal wie deren Erstellung notiert wird.

Ja, ich weiß. Der Knackpunkt bleibt, wieso Objekte bei Verkettung mit einer Zeichenkette keinen Stringkontext erzeugen.

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 []), oder sind es reine Datenbereiche, die vom Interpreter in einem Stack verwaltet werden?