nicht angemeldet
Hallo,
Primitive Werte »haben« genauso Methoden insofern, dass sie intern ständig in die entsprechenden Objekte »umgewandelt« werden.
Das hatte ich bei der Antwort von Tim anders verstanden (Stichworte: eigene toString()-Methoden, toPrimitive()).
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.
Keine Ahnung, wie das hinter den Kulissen gelöst ist - Objekte, wie man ihnen in JavaScript begegnen, sind natürlich auch nur Abstraktionen. Wie da die C++-Umsetzung aussieht, weiß ich nicht, aber der Witz in JavaScript ist eben, dass man sich darüber auch wenig Gedanken machen muss. (Der Teil ist auch nirgendwo standardisiert. Warum auch.)
Ok, das hatte ich nicht bedacht. EcmaScript ist ja nur sozusagen ein standardisiertes "Interface", das völlig unterschiedlich im "Backend" implementiert werden kann. Könnte also auch jemand herkommen und z. B. einen Interpreter in VB schreiben.
Und wenn length tatsächlich eine Eigenschaft von a ist, so muß sie besonders geschützt sein.
Siehe auch </archiv/2007/10/t159610/>
Sie ist als DontEnum, DontDelete festgelegt.Man kann sie ja zum Beipiel nicht mit einem String überschreiben.
Kann man schon versuchen. Wird aber ignoriert werden, weil der String keine sinnvolle Zahl ergibt:
http://bclary.com/2004/11/07/ecma-262.html#a-15.4.5.1
»»
Ja, also geschützt.
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?
Nein, jeder Function-Scope hat sein eigenes arguments-Objekt, siehe Link im letzten Posting.
Wenn das gar nicht standardisiert ist, kann man eigentlich keine Aussagen darüber machen. In JScript, nur als Beispiel, könnte es ja ganz anders sein.
Sind die lokalen Variablen dann nur temporär (persistente Eigenschaften würden den Speicher zumüllen).
Natürlich, solange ein Scope noch irgendwo »konserviert« ist (Stichwort Closures), existieren die lokalen Variablen, ansonsten werden sie sofort aus dem Speicher geräumt.
Ich meine nicht, wie der Zugriff eines JS-Skripts geregelt ist, das ist klar. Und ich vermute auch, die belegten Speicherbereiche werden freigegeben. Aber es könnte dennoch ein Singletonobjekt oder ähnliches geben, wo alle lokalen Variablen drin landen. Weil JS nicht standardisiert ist usw. ...
»arguments« ist ja kein wirklich unabhängig vom Scope existierendes Objekt, sondern nur eine Zugriffsweise.
Und das ist Teil meiner Fragen. Wird arguments temporär während der Ausführung einem Funktionsobjekt zugewiesen, gibt es temporär während der Ausführung ein unabhängiges "Ausführungsobjekt" oder werden lokale Variablen sonstwie gespeichert? Andererseits bliebe es jedem, der einen JS-Interpreter schreibt, selbst überlassen, wie er das macht, da es ja offensichtlich keinen Standard gibt.
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.
PHP ist kein Vergleich, weil es keine konsequent objektorientierte Sprache ist. Das Problem ergibt sich nur in solchen. Ein String ist in PHP kein Objekt, hat keine Methoden und kann auch keine Member vom Prototyp erben.
Das mag sein. Aber das klärt nicht, wieso es überhaupt auch für die skalaren Datentypen diese Objektverwirklichung gibt. Ich denke nicht, man kann C++ nicht als stark, wenn vielleicht auch nicht konsequent, objektorintiert bezeichnen. Dort gibt es eine klare Abgrenzung zwischen skalaren und höheren Datentypen.
Ich denke mal eher, Java, Ruby oder Python wären in dieser Hinsicht mit JavaScript vergleichbare Sprachen, mit denen kenne ich mich aber überhaupt nicht aus. (Tiiim!)
Java kenne ich auch zuwenig, die anderen gar nicht. Soweit ich weiß, ist dort ein String einfach nur ein String.
Ja, aber früher konnte man ja über funktionsname.lokaleVariable auf sie zugreifen.
Mit Sicherheit nicht.
Ich bin mir fast sicher ;) Mal mit einem alten Netscape ausprobieren!
Ich glaube mit arguments geht das immer noch.
Ja, aber Funktionsname.arguments war mal von Netscape JavaScript eingeführt und ist jetzt deprecated, in ECMAScript ist arguments eine lokale Variable.
Ich weiß. Aber was folgt daraus für ein Schluß? arguments existiert zweimal (einmal als temporäres Datum des "internen Objektes", einmal als Eigenschaft des eigentlichen Funktionsobjektes)? Und wie ist es bei length? Das wird ja nun wirklich nicht wie eine lokale Variable adressiert.