Navigieren in TCP-Proposals: Von der Fehlerbehandlung bis zu Iterator.range

Die Reise eines Praktikanten durch die Verbesserungen von SpiderMonkey und der JavaScript-Engine

Als ich den Iterator.range-Vorschlag und die darin enthaltenen Algorithmen zum ersten Mal sah, war ich mir nicht sicher, ob ich ihn hacken könnte. Als Outreachy-Mitarbeiter leisteten ich und andere Mitarbeiter einen Monat lang Beiträge, und dann wurde ein Praktikant ausgewählt, der an dem Vorschlag/der Spezifikation arbeitete.

Präambel

Ein paar Tage nach Beginn des Beitragszeitraums wurden mir Aufgaben für Outreachy-Mitwirkende zugewiesen, aber am wichtigsten war, dass mir der Vorschlag „ErrorIsError TC39“ zugewiesen wurde. 

Der erste Schritt zur Implementierung eines TC39-Vorschlags in SpiderMonkey (Mozilla JavaScript Engine) besteht darin, eine Präferenz dafür hinzuzufügen.
 
Dadurch kann die Funktion zur Laufzeit aktiviert oder deaktiviert werden, was wichtig ist, da wir eine Funktion erst dann standardmäßig aktivieren möchten, wenn wir sie ausreichend getestet haben, um sicher zu sein, dass sie unseren Benutzern keine Probleme bereitet. In diesem Fall erstellen wir eine Präferenz und setzen den Wert auf false.

Wie Sie sehen können, ist der Vorschlag bei der Implementierung mit JavaScript recht einfach und war die ursprüngliche Implementierung. Die Codeüberprüfung kam jedoch zurück und es war besser, den Vorschlag als native C-Funktion zu implementieren, was für mich ein Lernprozess war, sowohl im Hinblick auf den Grund als auch auf die Arbeit mit C.

Während des Prozesses stießen wir auf einige interessante Herausforderungen im Zusammenhang mit Cross-Compartment-Wrappern (CCWs) und intrinsischen Typprüfungen in JavaScript-Engines. 

---

Das Problem mit Cross-Compartment-Wrappern und ErrorObject-Prüfungen

Bei der Verarbeitung von Fehlerobjekten bestimmt die IsErrorObject-Funktion, ob ein gegebener Wert eine Instanz des ErrorObject-Typs ist. Ein kritischer Grenzfall tritt jedoch auf, wenn das Argument ein Cross-Compartment-Wrapper (CCW) für ein ErrorObject aus einem anderen Compartment ist. Die IsErrorObject-Prüfung berücksichtigt CCWs nicht direkt, da sie das zugrunde liegende Objekt verschleiern.

Implementierungskontext: Im Code zur Handhabung intrinsischer Typprüfungen wird die Funktion intrinsic_IsInstanceOfBuiltin verwendet, um zu prüfen, ob ein Objekt von einem bestimmten Typ ist. Während es funktioniert, wenn es auf diesen Wert angewendet wird; vorausgesetzt, es ist bereits ausgepackt; Es werden keine Argumente verarbeitet, die möglicherweise noch von CCWs umschlossen werden.

Die vorgeschlagene Lösung: Eine dedizierte native Funktion

Um dieses Problem anzugehen, umfasst die Lösung Folgendes:
1. Hinzufügen einer neuen nativen Funktion: Eine dedizierte native Funktion wird erstellt, um CCWs transparent zu verarbeiten durch:

• CCWs auspacken.
• Testen, ob das entpackte Objekt vom Typ ErrorObject ist.
• Überprüfung des Objekttyps in einem zusammenhängenden Vorgang.

2. Selbstgehostete Komplexität beseitigen:
Durch die Implementierung dieser neuen Funktion als JSNative können wir den Prozess rationalisieren und alle Vorgänge innerhalb einer einzigen nativen Funktion ausführen, ohne auf selbst gehostete Helfer angewiesen zu sein.

Warum dieser Ansatz?

Behandelt Nicht-Objekt-Fälle: Die neue Funktion integriert Prüfungen, ob der Wert überhaupt ein Objekt ist, bevor mit dem Entpacken fortgefahren wird.
Vereinfacht die Spezifikationsausrichtung: Da CCWs ein Implementierungsdetail und nicht Teil der TC39-JavaScript-Spezifikation sind, stellen diese Änderungen sicher, dass das Verhalten mit der Spezifikation übereinstimmt und gleichzeitig Diskrepanzen vermieden werden.

---

Das Obige bestand aus 45 Codezeilen, ausgenommen zwei Testdateien: eine für JIT-kompilierte Tests (Just-In-Time) und eine weitere für Test262-Tests/Dateien. Mit diesen 45 Codezeilen war ich jedoch in der Lage:

• Erfahren Sie, wo sich vordefinierte Fehlermeldungen in der Mozilla-Codebasis befinden und wie Sie sie verwenden. Dies erwies sich als praktisch, als ich Fehlermeldungen für Iterator.range definieren musste.
• Nächtliche und nächtliche Builds verstehen.
• Codekonsistenz: Passen Sie meinen Code an, um die TC39-Spezifikationen zu erfüllen, und vermeiden Sie Abkürzungen für neu hinzugefügten Code gemäß Mozilla-Standards.

Woran ich gerade arbeite: Iterator.range

Nachdem ich mich während meines Outreachy-Beitragszeitraums mit der Komplexität von Cross-Compartment-Wrappern beschäftigt und die Fehlerobjektbehandlung verbessert hatte, richtete ich meine Aufmerksamkeit auf etwas ebenso Spannendes: den Iterator.range-Vorschlag für mein Mozilla Outreachy-Praktikum.

Für diejenigen, die es nicht kennen: Iterator.range ist eine Ergänzung zu den TC39-Vorschlägen für JavaScript, die darauf abzielt, Iteratoren vielseitiger zu machen. Diese Methode bietet eine effiziente Möglichkeit zum Generieren von Wertebereichen, die besonders in der alltäglichen Programmierung nützlich sein kann, z. B. beim Durchlaufen einer Zahlenfolge oder beim Erstellen schrittbasierter Schleifen.
Das Konzept selbst mag einfach erscheinen; Generieren Sie eine Reihe von Werten von einem Startpunkt bis zu einem Endpunkt. Die Implementierung in SpiderMonkey erweist sich jedoch als große Herausforderung.

Im Gegensatz zur vorherigen ErrorObject-Arbeit, die die Handhabung abstrakter Operationen und nativer C-Funktionen umfasste, erfordert Iterator.range einen tiefen Einblick in die interne Funktionsweise von JavaScript-Iteratoren und wie SpiderMonkey diese Funktionen auf Engine-Ebene integriert.

Als ich mit der Arbeit an Iterator.range begann, war die erste Implementierung - ähnlich zu dem, was ich für den ErrorIsError-Vorschlag getan hatte, durchgeführt worden, d. h. Hinzufügen einer Präferenz für den Vorschlag und Ermöglichen des Zugriffs auf die integrierte Funktion in der JavaScript-Shell.

Der Iterator.range hat einfach „false“ zurückgegeben, einen Stub, der darauf hinweist, dass die tatsächliche Implementierung von Iterator.range in der Entwicklung war oder noch nicht vollständig implementiert war, und da kam ich ins Spiel.

Zunächst habe ich eine CreateNumericRangeIterator-Funktion erstellt, die an die Iterator.range-Funktion delegiert. Anschließend habe ich die ersten drei Schritte innerhalb der Iterator.range-Funktion implementiert.
Als nächstes habe ich Variablen und Parameter für den Datentyp NUMBER-RANGE in der Funktion CreateNumericRangeIterator initialisiert.

Ich habe mich auf die Implementierung von Sequenzen konzentriert, die um eins ansteigen, wie zum Beispiel Iterator.range(0, 10). Außerdem habe ich die Funktion „CreateNumericRangeIterator“ aktualisiert, um IteratorRangeGenerator (der Schritt 18 der Range Proposal-Spezifikation verarbeitet) mit den entsprechenden Argumenten aufzurufen, passend zu Schritt 19 der Spezifikation, und Tests hinzugefügt, um seine Funktionalität zu überprüfen.
Diese Woche untersuche ich, wie man den Prototyp für von Iterator.range zurückgegebene Generatoren richtig einrichtet. 

Meine Arbeit für die nächsten Wochen/Monate umfasst unter anderem:

• Legen Sie den richtigen Prototyp für den von Iterator.range zurückgegebenen Generator fest.
• Unterstützt BigInt in Iterator.range.
• Unterstützen Sie andere Sequenzen, da ich vorerst nur Sequenzen abgedeckt habe, die um eins ansteigen.
• Fügen Sie für die oben genannten Punkte geeignete Tests hinzu.

Das könnte Ihnen auch gefallen:

Open Source entschlüsseln: Vokabeln, die ich auf meiner Outreachy-Reise gelernt habe

Möchten Sie ein Remote-Praktikum mit freier Software?

Das obige ist der detaillierte Inhalt vonNavigieren in TCP-Proposals: Von der Fehlerbehandlung bis zu Iterator.range. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!