Navigation dans TCProposals : de la gestion des erreurs à Iterator.range

Parcours d'un stagiaire à travers les améliorations du moteur SpiderMonkey et JavaScript

La première fois que j'ai vu la proposition Iterator.range et les algorithmes à l'intérieur, je n'étais pas sûr de pouvoir la pirater. En tant que contributeur Outreachy, moi et d'autres contributeurs contribuerions pendant un mois, puis un stagiaire serait choisi pour travailler sur la proposition/spécification.

Préambule

Quelques jours après le début de la période de contribution, on m'a assigné des tâches désignées aux contributeurs d'Outreachy, mais plus important encore, on m'a attribué la proposition ErrorIsError TC39. 

La première étape pour implémenter une proposition TC39 dans SpiderMonkey (Mozilla JavaScript Engine) consiste à lui ajouter une préférence.
 
Cela permet d'activer ou de désactiver la fonctionnalité au moment de l'exécution, ce qui est important, car nous ne souhaitons pas activer une fonctionnalité par défaut tant que nous ne l'avons pas suffisamment testée pour être sûrs qu'elle ne posera pas de problèmes à nos utilisateurs. Dans ce cas, nous créons une préférence et définissons la valeur sur false.

Comme vous pouvez le voir, lorsqu'elle est implémentée avec JavaScript, la proposition est assez simple et constitue la mise en œuvre initiale. Cependant, la révision du code est revenue et il était préférable d'implémenter la proposition en tant que fonction C native, ce qui était un processus d'apprentissage pour moi, tant en termes de raisonnement que de travail avec C .

Au cours du processus, nous avons rencontré des défis intéressants impliquant des wrappers multi-compartiments (CCW) et des vérifications de type intrinsèques dans les moteurs JavaScript. 

---

Le problème avec les wrappers inter-compartiments et les vérifications ErrorObject

Lors de la gestion des objets Error , la fonction IsErrorObject détermine si une valeur donnée est une instance du type ErrorObject. Cependant, un cas critique survient lorsque l’argument est un wrapper inter-compartiments (CCW) pour un ErrorObject provenant d’un autre compartiment. La vérification IsErrorObject ne tient pas directement compte des CCW, car elles masquent l'objet sous-jacent.

Contexte d'implémentation : Dans le code gérant les vérifications de type intrinsèque, la fonction intrinsic_IsInstanceOfBuiltin est utilisée pour vérifier si un objet est d'un type spécifique. Bien que cela fonctionne lorsqu'il est appliqué à cette valeur ; en supposant qu'il soit déjà déballé ; il ne gère pas les arguments qui pourraient encore être enveloppés par les CCW.

La solution proposée : une fonction native dédiée

Pour résoudre ce problème, la solution implique :
1. Ajout d'une nouvelle fonction native : Une fonction native dédiée est créée pour gérer les CCW de manière transparente par :

• Déballage des CCW.
• Test si l'objet non emballé est de type ErrorObject.
• Vérification du type d'objet en une seule opération cohérente.

2. Suppression de la complexité auto-hébergée :
En implémentant cette nouvelle fonction en tant que JSNative, nous pouvons rationaliser le processus, en effectuant toutes les opérations au sein d'une seule fonction native sans compter sur des assistants auto-hébergés.

Pourquoi cette approche ?

Gère les cas non-objet : La nouvelle fonction intègre des vérifications pour savoir si la valeur est même un objet avant de procéder à son déballage.
Simplifie l'alignement des spécifications : Étant donné que les CCW sont un détail d'implémentation et ne font pas partie de la spécification JavaScript TC39, ces modifications garantissent que le comportement s'aligne sur la spécification tout en évitant les divergences.

---

Ce qui précède se composait de 45 lignes de code, à l'exclusion de deux fichiers de test : un pour les tests compilés JIT (Just-In-Time) et un autre pour les tests/fichiers Test262. Cependant, grâce à ces 45 lignes de code, j'ai pu :

• Découvrez où se trouvent les messages d'erreur prédéfinis dans la base de code Mozilla et comment les utiliser. Cela s'est avéré utile lorsque j'ai eu besoin de définir des messages d'erreur pour Iterator.range.
• Comprenez les builds nocturnes et nocturnes.
• Cohérence du code : adaptez mon code pour répondre aux spécifications TC39 et évitez les raccourcis pour le code nouvellement ajouté conformément aux normes Mozilla.

Sur quoi je travaille actuellement : Iterator.range

Après avoir plongé dans les complexités des wrappers multi-compartiments et amélioré la gestion d'ErrorObject pendant ma période de contribution Outreachy, j'ai tourné mon attention vers quelque chose d'aussi passionnant : la proposition Iterator.range pour mon stage Mozilla Outreachy.

Pour ceux qui ne sont pas familiers, Iterator.range est un ajout aux propositions TC39 pour JavaScript, visant à rendre les itérateurs plus polyvalents. Cette méthode introduit un moyen efficace de générer des plages de valeurs, qui peut être particulièrement utile dans la programmation quotidienne, comme par exemple parcourir une séquence de nombres ou créer des boucles basées sur des étapes.
Le concept lui-même peut paraître simple ; générer une série de valeurs d'un point de départ à un point final, mais son implémentation dans SpiderMonkey s'avère être un excellent défi.

Contrairement au travail précédent sur ErrorObject, qui impliquait la gestion d'opérations abstraites et de fonctions C natives, Iterator.range nécessite une analyse approfondie du fonctionnement interne des itérateurs JavaScript et de la manière dont SpiderMonkey intègre ces fonctionnalités au niveau du moteur.

Quand j'ai commencé à travailler sur Iterator.range, l'implémentation initiale - similaire à ce que j'avais fait pour la proposition ErrorIsError avait été effectuée, c'est-à-dire ; ajouter une préférence pour la proposition et rendre le module intégré accessible dans le shell JavaScript.

Iterator.range a simplement renvoyé false, un stub indiquant que l'implémentation réelle d'Iterator.range était en cours de développement ou n'était pas entièrement implémentée, c'est là que je suis intervenu.

Pour commencer, j'ai créé une fonction CreateNumericRangeIterator qui délègue à la fonction Iterator.range. Suite à cela, j'ai implémenté les trois premières étapes au sein de la fonction Iterator.range.
Ensuite, j'ai initialisé les variables et les paramètres pour le type de données NUMBER-RANGE dans la fonction CreateNumericRangeIterator.

Je me suis concentré sur l'implémentation de séquences qui augmentent de un, comme Iterator.range(0, 10). J'ai également mis à jour la fonction CreateNumericRangeIterator pour invoquer IteratorRangeGenerator (qui gère l'étape 18 de la spécification Range Proposal) avec les arguments appropriés, en s'alignant sur l'étape 19 de la spécification, et j'ai ajouté des tests pour vérifier sa fonctionnalité.
Cette semaine, j'explore comment configurer correctement le prototype pour les générateurs renvoyés par Iterator.range. 

Mon travail pour les prochaines semaines/mois comprend, sans s'y limiter :

• Définissez le prototype approprié pour le générateur renvoyé par Iterator.range.
• Supporte BigInt dans Iterator.range.
• Supportez d'autres séquences, car je n'ai couvert que les séquences qui augmentent de un pour l'instant.
• Ajoutez des tests adéquats pour ce qui précède.

Vous aimerez peut-être aussi :

Décoder l'Open Source : le vocabulaire que j'ai appris au cours de mon parcours de sensibilisation

Vous voulez un stage à distance pour travailler sur des logiciels libres ?

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!