Plusieurs autres langages de programmation utilisent par défaut l'espace de noms/environnement local plutôt qu'un environnement global. Les experts JMP affirment que NamesDefaultToHere(1) est le BKM à chaque fois que l'écriture de scripts est généralement appropriée pour les nouveaux scripts afin d'éviter les conflits avec d'autres scripts JMP. Il serait plus pratique de définir NamesDefaultToHere(0) lorsque vous souhaitez qu'un script soit dans l'espace de noms global plutôt que de définir chaque script avec l'argument "true"
Salut @cnattrass , Merci pour votre suggestion! Nous avons pris en compte votre demande et la prendrons en considération.
Avoir un espace de noms global par défaut est une décision de conception extrêmement mauvaise, à mon avis, même si je comprends que cela peut être nécessaire pour une compatibilité ascendante avec les scripts JSL écrits dans des versions antérieures de JMP.
Je pense que tout nouveau codeur JSL apprend cela à ses dépens lorsque des choses étranges et difficiles à déboguer commencent à se produire en raison de collisions de noms de variables avec plusieurs scripts ; en particulier, avec les détritus laissés par les scripts qui ont été exécutés précédemment sous l'espace de noms global.Étant donné que les variables ne nécessitent pas de déclaration dans JSL et que l'espace de noms global est la valeur par défaut, je pense qu'il est absolument crucial d'initialiser toutes les variables à un état vide en haut de mon script pour être certain que des valeurs inattendues n'empiètent pas sur mon script, provoquant confusion et chaos.
Bien sûr, c'est aussi une bonne pratique de mettre Noms par défaut ici (1); en haut de chaque script JSL jamais écrit, partout, toujours, à moins que le script besoins utiliser l'espace de noms global pour une raison étrange.Même dans une telle situation, je pense qu'il serait préférable de définir l'espace de noms par défaut sur Local et de faire référence à toutes les variables globales comme espace de noms global en utilisant explicitement le ::nom_global syntaxe.Ainsi, si l'espace de noms global par défaut est vraiment nécessaire pour la compatibilité ascendante, nous devrions avoir la possibilité pour l'éditeur de script de toujours insérer Noms par défaut ici (1); en haut de tous les nouveaux scripts, au lieu d'exiger que le codeur s'en souvienne et le tape à chaque fois .
Même avec ces précautions, je rencontre encore parfois des cas extrêmes où des collisions se produisent.Par exemple, le Addition et Produit les fonctions incluent une variable implicite nommée je par défaut.C'est bien lorsqu'il est utilisé dans un script dans lequel j'ai déjà défini l'espace de noms local par défaut.Mais qu’en est-il des formules de colonnes ?Normalement, je ne considère pas les formules de colonnes comme des scripts, même si c'est exactement ce qu'elles sont.Je les édite graphiquement à l'aide de l'éditeur de formule GUI.Cela ne m’avait jamais traversé l’esprit.
Eh bien, la première fois que j'ai utilisé un Addition dans une formule de colonne, il m'est également arrivé d'exécuter un script de table dans lequel j'avais oublié de définir l'espace de noms local, dans lequel j'utilisais un Pour boucle avec l'itérateur comme je .Sans surprise, cela a conduit à la confusion et au chaos.L'application ne répondait plus, coincée dans une boucle infinie et j'ai dû arrêter la tâche.Il m'a ensuite fallu réessayer encore quelques fois avant de me rendre enfin compte de l'erreur terrible et obscure que j'avais commise, fomentée par le piège tendu par le Addition C'est un monde pernicieux je itérateur.Pour faire court, maintenant même dans les formules de colonnes, je double-clique sur l'éditeur de script et insère le Noms par défaut ici (1); .Aucun script n'est sûr sans lui .
