Mehrere andere Programmiersprachen verwenden standardmäßig den lokalen Namespace/die lokale Umgebung und nicht eine globale Umgebung. JMP-Experten sagen, dass NamesDefaultToHere(1) bei jeder Skripterstellung der BKM ist, da normalerweise der lokale Namespace für neue Skripts geeignet ist, um Konflikte mit anderen JMP-Skripten zu vermeiden. Es wäre praktischer, NamesDefaultToHere(0) zu definieren, wenn Sie möchten, dass sich ein Skript im globalen Namespace befindet, anstatt jedes Skript mit dem Argument „true“ zu definieren
Hallo @cnattrass , Danke für deinen Vorschlag! Wir haben Ihre Anfrage erfasst und werden sie prüfen.
Meiner Meinung nach ist es eine äußerst schlechte Designentscheidung, den globalen Namensraum als Standard zu verwenden, obwohl ich weiß, dass dies aus Gründen der Abwärtskompatibilität mit JSL-Skripten, die in früheren Versionen von JMP geschrieben wurden, erforderlich sein kann.
Ich denke, dass jeder neue JSL-Programmierer dies auf die harte Tour lernt, wenn aufgrund von Variablennamenkollisionen mit mehreren Skripten seltsame, schwer zu debuggende Dinge passieren. insbesondere mit den Rückständen, die von Skripten hinterlassen wurden, die zuvor unter dem globalen Namensraum ausgeführt wurden.Da für Variablen keine Deklaration in JSL erforderlich ist und der globale Namespace die Standardeinstellung ist, halte ich es für absolut wichtig, alle Variablen oben in meinem Skript in einen leeren Zustand zu initialisieren, um sicherzustellen, dass keine unerwarteten Werte in mein Skript eindringen und Probleme verursachen Verwirrung und Chaos.
Natürlich ist es auch eine gute Übung, dies zu tun Namen standardmäßig hier(1); ganz oben in jedem einzelnen JSL-Skript, das jemals geschrieben wurde, überall und immer, außer im Skript Bedürfnisse aus irgendeinem seltsamen Grund den globalen Namespace zu verwenden.Selbst in einer solchen Situation wäre es meiner Meinung nach besser, den Standard-Namespace auf Local zu setzen und alle globalen Variablen explizit als globalen Namespace zu bezeichnen ::globaler_name Syntax.Wenn also der standardmäßige globale Namespace aus Gründen der Abwärtskompatibilität wirklich erforderlich ist, sollten wir die Option haben, dass der Skripteditor immer einfügt Namen standardmäßig hier(1); am Anfang aller neuen Skripte, anstatt dass sich der Programmierer dies jedes Mal merken und eingeben muss .
Trotz dieser Vorsichtsmaßnahmen stoße ich immer noch manchmal auf Grenzfälle, in denen es zu Kollisionen kommt.Zum Beispiel die Summe Und Produkt Funktionen enthalten eine implizite Variable mit dem Namen ich standardmäßig.Das ist in Ordnung, wenn es innerhalb eines Skripts verwendet wird, in dem ich bereits den lokalen Standard-Namespace festgelegt habe.Aber was ist mit Spaltenformeln?Normalerweise betrachte ich Spaltenformeln nicht als Skripte, obwohl sie genau das sind.Ich bearbeite sie grafisch mit dem GUI-Formeleditor.Es war mir nie in den Sinn gekommen.
Nun, das erste Mal, dass ich a Summe In einer Spaltenformel habe ich zufällig auch ein Tabellenskript ausgeführt, bei dem ich vergessen hatte, einen lokalen Namespace festzulegen, in dem ich a verwendet habe Für Schleife mit dem Iterator as ich .Es überrascht nicht, dass dies zu Verwirrung und Chaos führte.Die Anwendung reagierte nicht mehr, blieb in einer Endlosschleife hängen und ich musste die Aufgabe abbrechen.Dann musste ich es noch ein paar Mal versuchen, bevor mir endlich der schreckliche, obskure Fehler klar wurde, den ich gemacht hatte, angefacht durch die Falle, die mir gestellt worden war Summe Es ist verderblich, global ich Iterator.Um es kurz zu machen: Jetzt klicke ich sogar in Spaltenformeln doppelt auf den Skripteditor und füge das ein Namen standardmäßig hier(1); .Kein Skript ist ohne es sicher .