Il ne me semble pas que les règles de portée de Javascript soient si diaboliques. Les règles sur `this` sont un peu bizarre (mais ce n'est pas une règle de portée à proprement parler, c'est une règle sur le passage implicite d'un paramètre), et les règles sur `var` sont médiocres, mais honnêtement `var` ne me paraît pas plus mauvais que la méthode Coffeescript. Par ailleurs la bonne solution aux problèmes de portée a déjà été mise en place, c'est le `let` ajouté par Mozilla, qui se comporte tout à fait comme il faut (JavaScript 1.7 : we finally got variable binding right !). Évidemment IE6 ne le supporte pas...
Il me semble qu'il y a deux solutions différentes de celle choisie par CoffeeScript :
- accepter les limitations de JS<1.7 en proposant un mécanisme de définition de la portée d'une variable (règle le problème du shadowing) en précisant (par avertissement ou carrément erreur) qu'il ne peut être utilisé qu'en début de fonction, et pas de n'importe quel bloc; c'est honnête, simple et ça marche plutôt bien
- utiliser un préprocesseur pour générer "le bon comportement" dans chaque bloc même pas de fonction, ce qui revient à émuler le comportement de `let`; c'est plus compliqué mais plus puissant aussi
Dans le deuxième cas, si on met dans un bloc local `local x` (par exemple), l'implémentation pourrait par exemple choisir en interne un nom frais (du genre `x32`) et utiliserait ce nom à la place de `x` dans le bloc concerné. N'étant pas un spécialiste de Javascript, je ne peux pas garantir que ce soit la meilleur façon de faire, mais cela me semble très raisonnable pour commencer (un soucis que je vois est que la génération à la compilation de nouvelles variables locales étonner les gens qui font n'importe quoi avec l'introspection, comme afficher la liste des variables définie dans le bloc et leur valeur).
En fait fondamentalement je trouve que la solution de Coffeescript est pire que `var`. La plupart de leurs modifications se limitent à une sorte de sucre syntaxique local qui rend une construction donnée plus facile à utiliser. Là, ils empêchent l'accès à une construction déjà existante (var), et considèrent comme bénéfice ce qui est en fait un défaut important (impossibilité de name shadowing), qui a un effet global et non local sur la sémantique du programme. Dans la logique d'une surcouche légère, il serait bien plus cohérent de permettre aux gens d'utiliser localement la construction `var` explicitement, s'ils en ont envie, et d'inférer tout seul comme ils le font actuellement dans les autres cas.
[^] # Re: C'est pas Coffescript mais javascript le problème.
Posté par gasche . En réponse à la dépêche Agrémentez votre JavaScript avec CoffeeScript 1.0. Évalué à 3.
Il me semble qu'il y a deux solutions différentes de celle choisie par CoffeeScript :
- accepter les limitations de JS<1.7 en proposant un mécanisme de définition de la portée d'une variable (règle le problème du shadowing) en précisant (par avertissement ou carrément erreur) qu'il ne peut être utilisé qu'en début de fonction, et pas de n'importe quel bloc; c'est honnête, simple et ça marche plutôt bien
- utiliser un préprocesseur pour générer "le bon comportement" dans chaque bloc même pas de fonction, ce qui revient à émuler le comportement de `let`; c'est plus compliqué mais plus puissant aussi
Dans le deuxième cas, si on met dans un bloc local `local x` (par exemple), l'implémentation pourrait par exemple choisir en interne un nom frais (du genre `x32`) et utiliserait ce nom à la place de `x` dans le bloc concerné. N'étant pas un spécialiste de Javascript, je ne peux pas garantir que ce soit la meilleur façon de faire, mais cela me semble très raisonnable pour commencer (un soucis que je vois est que la génération à la compilation de nouvelles variables locales étonner les gens qui font n'importe quoi avec l'introspection, comme afficher la liste des variables définie dans le bloc et leur valeur).
En fait fondamentalement je trouve que la solution de Coffeescript est pire que `var`. La plupart de leurs modifications se limitent à une sorte de sucre syntaxique local qui rend une construction donnée plus facile à utiliser. Là, ils empêchent l'accès à une construction déjà existante (var), et considèrent comme bénéfice ce qui est en fait un défaut important (impossibilité de name shadowing), qui a un effet global et non local sur la sémantique du programme. Dans la logique d'une surcouche légère, il serait bien plus cohérent de permettre aux gens d'utiliser localement la construction `var` explicitement, s'ils en ont envie, et d'inférer tout seul comme ils le font actuellement dans les autres cas.