TCProposal のナビゲート: エラー処理から Iterator.range まで-jsチュートリアル-php.cn

TCProposal のナビゲート: エラー処理から Iterator.range まで

Linda Hamilton

リリース： 2025-01-09 07:30:39

オリジナル

644 人が閲覧しました

SpiderMonkey と JavaScript エンジンの強化を通じたインターンの旅

Iterator.range プロポーザルとその内部のアルゴリズムを初めて見たとき、それをハッキングできるかどうかはわかりませんでした。 Outreachy の寄稿者として、私と他の寄稿者は 1 か月間寄稿し、その後 1 人のインターンが提案/仕様に取り組むために選ばれます。

Navigating TCProposals: From Error Handling to Iterator.range

前文

貢献期間が始まって数日後、私は Outreachy の貢献者に指定されたタスクを割り当てられましたが、最も重要なのは、ErrorIsError TC39 提案が割り当てられたことです。

SpiderMonkey (Mozilla JavaScript Engine) で TC39 プロポーザルを実装するための最初のステップは、TC39 プロポーザルの設定を追加することです。

これにより、実行時に機能を有効または無効にできるようになります。これは重要です。十分にテストして、ユーザーに問題が発生しないと確信できるまでは、機能をデフォルトで有効にしたくないからです。この場合、プリファレンスを作成し、値を false に設定します。

ご覧のとおり、JavaScript で実装すると、この提案は非常に簡単で、最初の実装となりました。しかし、コードレビューが戻ってきて、提案をネイティブ C 関数として実装する方が良いと判断されました。これは、理由と C の操作の両方の点で、私にとって学習プロセスでした。

このプロセス中に、クロスコンパートメントラッパー (CCW) と JavaScript エンジンの組み込み型チェックに関連するいくつかの興味深い課題に遭遇しました。

クロスコンパートメントラッパーとErrorObjectチェックの問題

Error オブジェクトを処理する場合、IsErrorObject 関数は、指定された値が ErrorObject 型のインスタンスであるかどうかを判断します。ただし、引数が別のコンパートメントからの ErrorObject のクロスコンパートメントラッパー (CCW) である場合、重大なエッジケースが発生します。 CCW は基になるオブジェクトを不明瞭にするため、IsErrorObject チェックでは CCW を直接考慮しません。

実装コンテキスト: 組み込み型チェックを処理するコードでは、オブジェクトが特定の型であるかどうかをチェックするために intrinsic_IsInstanceOfBuiltin 関数が使用されます。 this 値に適用すると機能します。すでにアンラップされていると仮定します。 CCW によってまだラップされている可能性のある引数は処理されません。

提案されたソリューション: 専用のネイティブ関数

この問題に対処するには、次の解決策が必要です。
1.新しいネイティブ関数の追加: CCW を透過的に処理するための専用のネイティブ関数が次の方法で作成されます:

CCW のラップを解除します。
ラップされていないオブジェクトのタイプが ErrorObject であるかどうかをテストします。
1 つのまとまった操作でオブジェクトタイプを検証します。

2.自己ホスト型の複雑性の削除:
この新しい関数を JSNative として実装することで、プロセスを合理化し、自己ホスト型ヘルパーに依存せずに単一のネイティブ関数内ですべての操作を実行できます。

なぜこのアプローチなのか?

非オブジェクトのケースの処理: 新しい関数は、値のラップ解除を続行する前に、値がオブジェクトであるかどうかのチェックを統合します。
仕様の調整の簡素化: CCW は実装の詳細であり、TC39 JavaScript 仕様の一部ではないため、これらの変更により、矛盾を回避しながら動作が仕様と一致することが保証されます。

上記は 2 つのテストファイルを除く 45 行のコードで構成されています。1 つは JIT (ジャストインタイム) コンパイルされたテスト用、もう 1 つは Test262 テスト/ファイル用です。ただし、この 45 行のコードを通じて、次のことができました。

Mozilla コードベース内の事前定義されたエラーメッセージの場所とその使用方法を学びます。これは、Iterator.range.
夜間ビルドと夜間ビルドを理解します。
コードの一貫性: TC39 仕様を満たすようにコードを調整し、Mozilla 標準に従って新しく追加されたコードの略記を避けます。

私が現在取り組んでいること: Iterator.range

Outreachy への貢献期間中に、クロスコンパートメントラッパーの複雑さを掘り下げ、ErrorObject 処理を強化した後、私は同様に刺激的なものに注目しました。それは、Mozilla Outreachy インターンシップでの Iterator.range 提案です。

馴染みのない人のために説明すると、Iterator.range は JavaScript の TC39 提案への追加であり、イテレーターの汎用性を高めることを目的としています。このメソッドは、値の範囲を生成する効率的な方法を導入します。これは、一連の数値の反復処理やステップベースのループの作成など、日常のプログラミングで特に役立ちます。
概念自体は単純に見えるかもしれません。開始点から終了点まで一連の値を生成することは、SpiderMonkey での実装が非常に困難であることが判明しています。

抽象操作やネイティブ C 関数の処理を必要とした以前の ErrorObject の作業とは異なり、Iterator.range では、JavaScript イテレータが内部でどのように動作するか、また SpiderMonkey がこれらの機能をエンジンレベルでどのように統合するかについて深く調べる必要があります。

私が Iterator.range の作業を開始したとき、ErrorIsError 提案に対して行ったことと同様の初期実装が行われていました。プロポーザルの設定を追加し、JavaScript シェルで組み込みにアクセスできるようにします。

Iterator.range は単純に false を返しました。これは、Iterator.range の実際の実装が開発中であるか完全に実装されていないことを示すスタブであり、ここで私が登場しました。

まず、Iterator.range 関数に委任する CreateNumericRangeIterator 関数を作成しました。続いて、最初の 3 つのステップを Iterator.range 関数内に実装しました。
次に、CreateNumericRangeIterator 関数で NUMBER-RANGE データ型の変数とパラメーターを初期化しました。

Iterator.range(0, 10) など、1 ずつ増加するシーケンスの実装に重点を置きました。また、仕様のステップ 19 に合わせて、適切な引数を使用して IteratorRangeGenerator (範囲提案仕様のステップ 18 を処理する) を呼び出すように CreateNumericRangeIterator 関数を更新し、その機能を検証するテストを追加しました。
今週は、Iterator.range によって返されるジェネレーターのプロトタイプを適切に設定する方法を検討します。

今後数週間/数か月の私の仕事には以下が含まれますが、これらに限定されません。