| Les deux révisions précédentes Révision précédente Prochaine révision | Révision précédente |
| cnam:utc503:td3 [2026/10/20 02:20] – jcheron | cnam:utc503:td3 [2026/10/20 09:17] (Version actuelle) – jcheron |
|---|
| ====== TD 3 : Fondamentaux de la programmation fonctionnelle en JavaScript ====== | ====== TD 3 : Pf en JS ====== |
| |
| <WRAP info round> | <WRAP info round> |
| | ''push'', ''pop'', ''shift'', ''unshift'', ''splice'', ''sort'', ''reverse'', ''fill'' | ''map'', ''filter'', ''reduce'', ''slice'', ''concat'', ''[...arr]'', ''toSorted'', ''toReversed'', ''with'' | | | ''push'', ''pop'', ''shift'', ''unshift'', ''splice'', ''sort'', ''reverse'', ''fill'' | ''map'', ''filter'', ''reduce'', ''slice'', ''concat'', ''[...arr]'', ''toSorted'', ''toReversed'', ''with'' | |
| |
| Gardez ce tableau sous les yeux : ''sort'' et ''reverse'' sont des pièges classiques. | ''sort'' et ''reverse'' sont des pièges classiques. |
| </WRAP> | </WRAP> |
| |
| ==== 1.1 - Écrire une fonction pure ==== | ==== 1.1 - Écrire une fonction pure ==== |
| |
| * Écrire ''double(numbers)'' qui retourne un **nouveau** tableau où chaque nombre est doublé. **Interdiction** d'utiliser ''for'', ''while'' ou ''forEach'' : utilisez ''map''. | * Écrire ''double(numbers)'' qui retourne un **nouveau** tableau où chaque nombre est doublé. |
| * Écrire les tests suivants : | * Écrire les tests suivants : |
| |
| </sxh> | </sxh> |
| |
| <WRAP tip round> | |
| **Indice pour D** : une fonction pure ne peut pas "aller chercher" l'heure. Que faut-il changer dans sa signature ? | |
| </WRAP> | |
| |
| ==== 1.4 - Pour aller plus loin : l'impureté cachée ==== | ==== 1.4 - Pour aller plus loin : l'impureté cachée ==== |
| * Citez un cas où la mutation locale est acceptable (ex : accumulateur dans un ''reduce'' non exposé). À quelle condition préserve-t-elle la pureté //vue de l'extérieur// ? | * Citez un cas où la mutation locale est acceptable (ex : accumulateur dans un ''reduce'' non exposé). À quelle condition préserve-t-elle la pureté //vue de l'extérieur// ? |
| </WRAP> | </WRAP> |
| |
| Je ne connaissais pas la balise ''<sxh>''. C'est celle du plugin SyntaxHighlighter pour DokuWiki, et je n'y ai pas pensé. Je suis parti sur ''<code javascript>'' puis sur des ''%%...%%'', alors que les blocs ''<sxh javascript>'' sont la bonne solution ici. | |
| Elle règle aussi le problème d'imbrication, parce que le contenu d'un bloc ''<sxh>'' n'est pas interprété par DokuWiki. Les apostrophes ne risquent plus de casser le reste de la page. | |
| Dans la version ci-dessous : | |
| |
| Code : chaque extrait est dans un vrai bloc ''<sxh javascript>'', y compris les expressions courtes des listes. | |
| Texte : les noms de fonctions dans les phrases sont en monospace avec ''%%...%%'', jamais avec le double apostrophe. | |
| Code impératif de 5.1 : il est en un seul bloc au lieu d'une liste à puces. | |
| Jeu de données de l'exercice 5 : il est remis en JS dans un bloc, comme dans ton énoncé d'origine. | |
| |
| ===== Exercice 3 : Transparence référentielle ===== | ===== Exercice 3 : Transparence référentielle ===== |
| |
| * Rejouez une liste d'actions avec %%reduce%%. Observez le lien avec Redux et le pattern "état = fonction des événements passés". | * Rejouez une liste d'actions avec %%reduce%%. Observez le lien avec Redux et le pattern "état = fonction des événements passés". |
| | |
| |
| <WRAP todo round> | <WRAP todo round> |
| * La version fonctionnelle parcourt plusieurs fois le tableau (%%filter%%, %%map%%, %%reduce%%). Est-ce un problème ? Comment un //transducer// ou un évaluateur paresseux y répond-il ? À partir de quelle taille de données cela compte-t-il vraiment ? | * La version fonctionnelle parcourt plusieurs fois le tableau (%%filter%%, %%map%%, %%reduce%%). Est-ce un problème ? Comment un //transducer// ou un évaluateur paresseux y répond-il ? À partir de quelle taille de données cela compte-t-il vraiment ? |
| * Dans 5.6 (réducteur), pourquoi l'immutabilité rend-elle possible le "time travel debugging" et l'annulation (undo) ? | * Dans 5.6 (réducteur), pourquoi l'immutabilité rend-elle possible le "time travel debugging" et l'annulation (undo) ? |
| </WRAP | </WRAP> |
jcheron