663180_de-DE

liliconcom

Betreff: JMP-Compiler-Kontextbewusstsein verbessern – Status geändert in: Bestätigt

Danke für die Eingabe. Wir möchten den Benutzer darüber informieren, wenn er möglicherweise eine JMP-Kernfunktion überschreibt. Ich kann mir vorstellen, dass dies für einen erfahreneren Benutzer ärgerlich sein könnte. Wir werden dies mit unserem Entwicklungsteam teilen und prüfen, ob wir eine Möglichkeit bieten können, solche Warnmeldungen zu unterdrücken. Die Herausforderung wird darin bestehen, zu bestimmen, welche Warnmeldungen unterdrückt werden sollten oder könnten.  

 

Ich nehme an, wenn Sie solche Funktionen immer wieder definieren würden, könnte dies dazu führen, dass das Protokoll voll wird. Wie oft sehen Sie, dass dies in Ihren Skripten und den zugehörigen Protokolldateien passiert? Außerdem würde eine andere Definition der Funktion diese Art von Meldung im Protokoll verhindern, z

 

"test namespace":customprint=Function({}, "will  this print?");

Betreff: JMP-Compiler-Kontextbewusstsein verbessern – Status geändert in: Wird untersuchtBetreff: Verbessern Sie das Kontextbewusstsein des JMP-Compilers

Vielen Dank für Ihre Antwort – es ist kein allzu großes Ärgernis – es passiert, wenn AddinLoad ausgeführt wird und meine Klassen initialisiert werden – ich habe die Instanzgeneratoren auf die Verwendung der folgenden Methode umgestellt, um zu vermeiden, dass diese Meldungen für jeden in das Protokoll eingetragen werden neue Instanz.

 

Wenn es also etwas ist, das für Sie leicht zu erledigen ist, wäre das ganz nett, aber es hat keineswegs hohe Priorität.

 

new namespace( "test",
 {
  print = Function( {},
   show( "test" )
  )
 }
);

"test":print;

Betreff: Verbessern Sie das Kontextbewusstsein des JMP-Compilers

Ich glaube, dass dies eine bessere Lösung ist:

x=New Namespace( "This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!" );


x["print"] = Function( {},
 Print( "hello 1" )
);
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 1
// or 
y=namespace("This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!");
y["print"] = Function( {},
 Print( "hello 2" )
);
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 2
// or
namespace("This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!")["print"] = Function( {},
 Print( "hello 3" )
);
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 3
x:print(); // hello 3
y:print(); // hello 3

// the above is to work around the log message from variations on this:
x:print = Function( {},
 Print( "hello 4" )
); 
/*
The user-defined function "Print" conflicts with the JMP function "Print". 
Use a scoped reference (for example, Global:Print or Here:Print) to call 
your user-defined function. Other uses of "Print" in your script source 
will continue to call the JMP function.
*/
// which actually works...
"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print(); // hello 4
// logcapture() is a less pretty way to make the message go away.

// The associative array style assignment prevents JMP from looking up the "print"
// name in the usual way. 

// shownamespaces(); // there is only one; x and y are alternate ways to use it

Ich mag es nicht, Zuweisungsanweisungen (außer einfachen Konstanten) zur NewNameSpace-Argumentenliste hinzuzufügen, weil sie als Ausdrücke gespeichert werden, die noch ausgewertet werden müssen. In Ihrem Beispiel ist print also ein Ausdruck, der die Definition der Funktion enthält und bei jeder Verwendung erneut in die eigentliche Funktion umgewandelt wird, bevor die eigentliche Funktion ausgeführt werden kann. Es tut Erreichen Sie Ihr Ziel, denn es erstellt niemals eine Variable namens print, die eine Funktion enthält, sondern nur einen Ausdruck, der als Funktion ausgewertet wird.

z = New Namespace(
 "z",
 f = If( Is Missing( Beep() ), // this is evaluated later, on each access
  1,
  2
 )
);

z:f; // beep!

Ich stimme zu, die aktuelle Meldung sollte in diesem Fall nicht auftreten; Ich hoffe, dass es behoben wird.

 

Verbessern Sie das Kontextbewusstsein des JMP-Compilers

Was hat diese Wunschlistenanfrage inspiriert?An das Protokoll gesendete Nachrichten können langsam und für Benutzer verwirrend sein

 

Welche Verbesserung würden Sie sich wünschen?Überladen Sie das Protokoll nicht mit nutzlosen Nachrichten

 

Warum ist diese Idee wichtig?Eigentlich ist es eher ein Ärgernis.

 

Betrachten Sie die folgende JSL: Ich füge eine Funktion an den Namen „print“ innerhalb eines benutzerdefinierten Namespace an.

New Namespace( "This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!" );

"This is a NAMESPACE -- it is different than BUILTIN!!!!!!!!!!!!!!!":print = Function( {},
 Print( "Why does JMP think I am trying to overwrite a Builtin???" )
)

 

Warum erhalte ich diese Warnung?Ich versuche nicht, ein Builtin zu überschreiben.Ich weiß, dass ich den Namen in einen Namensraum einfüge und auf diese Weise auf den Wert dieses Namens zugreife.

 

Kann der JMP-Compiler erkennen, wann sich der Name in einem Namespace befindet, und diese Nachrichten nicht an das Protokoll senden?Ich verwende Namespaces, um benutzerdefinierte Klassen zu erstellen. Wenn also eine neue Instanz erstellt wird, wird das Protokoll mit diesen überflüssigen Nachrichten gespammt.

 

 

Automatisierung und SkripterstellungBetreff: Kontextbewusstsein des JMP-Compilers verbessern – Status geändert in: Bestätigt