Attention, je parle de la définition de variable locale, et non pas de variable toplevel comme le discute ta citation.
Un exemple : voici un bout de code Javascript utilisant let (donc pas portable mais passons, je choisis juste let pour avoir une portée classique)
[...]
if (x > y) {
let z = 12.7 * x + y;
do_something(z);
}
[...]
Je peux placer ce bout de code à n'importe quel endroit de mon code qui connaît x, y et do_something, sans me soucier du reste, et ça va marcher exactement comme je l'entends.
Maintenant si j'essaie de faire pareil en Coffeescript
[...]
if (x > y)
z = 12.7 * x + y;
do_something(z);
[...]
Ce code ne fait la même chose que siz n'existe pas déjà.
En effet
z = "foo"
if (x > y)
z = 12.7 * x + y;
do_something(z)
# z ne vaut plus "foo" !
Je n'ai pas moyen de dire (à part en encapsulant dans une fonction, ce qui est exactement ce que Coffeescript fait pour éviter les soucis de syntaxe de JavaScript; donc il faudrait refaire ça par dessus pour avoir une portée correcte) que je veux choisir un nouveau z qui n'affecte pas ce qui existe déjà.
Ça veut dire que si je veux déplacer un bout de code qui fait ça, et que je veux le mettre là, il faut que je renomme dans ce bout de code toutes les occurences de z vers un autre truc genre z1. Ça augmente l'effort de maintenance et c'est un bug qui ne demande qu'à arriver : on oublie de renommer l'un des z et on est mort... Bref, l'impossibilité de "masquer" des noms existants en déclarant une nouvelle variable locale est très gênante (d'ailleurs Erlang a aussi ce défaut, mais c'est un autre débat).
La réponse des auteurs de CoffeeScript est "oui mais ça pose problème que si tu as plusieurs niveaux de variables locales, donc plusieurs blocs imbriqués, et les blocs imbriqués c'est mal de toute façon". Je pense pour ma part que si un langage ne se comporte pas bien au niveau des définitions de variable locale, ça posera forcément problème à un moment où à un autre, même si les concepteurs aimeraient bien que tout le monde programme de la façon qui les arrange. Je n'ai pas envie d'utiliser un langage qui n'apporte pas cette garantie de base : ça fait des années qu'on sait comment gérer les variables locales de façon robuste (portée lexicale avec lieurs explicites), mais les concepteurs de langages continuent à ignorer ça et faire n'importe quoi.
[^] # Re: CoffeeScript
Posté par gasche . En réponse à la dépêche Dart va‐t‐il remplacer JavaScript comme langage dans les navigateurs ?. Évalué à 7.
Attention, je parle de la définition de variable locale, et non pas de variable toplevel comme le discute ta citation.
Un exemple : voici un bout de code Javascript utilisant
let(donc pas portable mais passons, je choisis justeletpour avoir une portée classique)Je peux placer ce bout de code à n'importe quel endroit de mon code qui connaît
x,yetdo_something, sans me soucier du reste, et ça va marcher exactement comme je l'entends.Maintenant si j'essaie de faire pareil en Coffeescript
[...]
if (x > y)
z = 12.7 * x + y;
do_something(z);
[...]
Ce code ne fait la même chose que si
zn'existe pas déjà.En effet
z = "foo"
if (x > y)
z = 12.7 * x + y;
do_something(z)
# z ne vaut plus "foo" !
Je n'ai pas moyen de dire (à part en encapsulant dans une fonction, ce qui est exactement ce que Coffeescript fait pour éviter les soucis de syntaxe de JavaScript; donc il faudrait refaire ça par dessus pour avoir une portée correcte) que je veux choisir un nouveau z qui n'affecte pas ce qui existe déjà.
Ça veut dire que si je veux déplacer un bout de code qui fait ça, et que je veux le mettre là, il faut que je renomme dans ce bout de code toutes les occurences de
zvers un autre truc genrez1. Ça augmente l'effort de maintenance et c'est un bug qui ne demande qu'à arriver : on oublie de renommer l'un deszet on est mort... Bref, l'impossibilité de "masquer" des noms existants en déclarant une nouvelle variable locale est très gênante (d'ailleurs Erlang a aussi ce défaut, mais c'est un autre débat).La réponse des auteurs de CoffeeScript est "oui mais ça pose problème que si tu as plusieurs niveaux de variables locales, donc plusieurs blocs imbriqués, et les blocs imbriqués c'est mal de toute façon". Je pense pour ma part que si un langage ne se comporte pas bien au niveau des définitions de variable locale, ça posera forcément problème à un moment où à un autre, même si les concepteurs aimeraient bien que tout le monde programme de la façon qui les arrange. Je n'ai pas envie d'utiliser un langage qui n'apporte pas cette garantie de base : ça fait des années qu'on sait comment gérer les variables locales de façon robuste (portée lexicale avec lieurs explicites), mais les concepteurs de langages continuent à ignorer ça et faire n'importe quoi.