Objet : Améliorer la reconnaissance du contexte du compilateur JMP - Statut modifié en : ReconnuMerci pour la contribution. Nous voulons informer l'utilisateur lorsqu'il écrase potentiellement une fonction JMP principale. Je peux voir comment cela pourrait être ennuyeux pour un utilisateur plus expert. Nous partagerons cela avec notre équipe de développement et verrons si nous pouvons fournir un moyen de supprimer les messages d'avertissement comme celui-ci. Le défi sera de savoir comment déterminer quels messages d'avertissement devraient ou pourraient être supprimés.
Je suppose que si vous définissiez des fonctions comme celle-ci encore et encore, cela pourrait entraîner le remplissage du journal. À quelle fréquence voyez-vous cela se produire dans vos scripts et les fichiers journaux associés ? De plus, définir la fonction différemment empêcherait ce type de message dans le journal, par exemple
"test namespace":customprint=Function({}, "will this print?");
Objet : Améliorer la reconnaissance du contexte du compilateur JMP - Statut modifié en : EnquêteObjet : Améliorer la sensibilité au contexte du compilateur JMPMerci pour votre réponse - ce n'est pas trop gênant - c'est lorsque AddinLoad s'exécute et que mes classes s'initialisent - j'ai changé les générateurs d'instance pour utiliser la méthode ci-dessous pour éviter de mettre ces messages dans le journal pour chaque nouvel exemple.
Donc, si c'est quelque chose qui se fait facilement de votre part, ce serait plutôt bien, mais ce n'est en aucun cas une priorité élevée.
new namespace( "test",
{
print = Function( {},
show( "test" )
)
}
);
"test":print;Objet : Améliorer la sensibilité au contexte du compilateur JMPJe pense que c'est une meilleure solution de contournement:
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
Je n'aime pas ajouter des instructions d'affectation (autres que de simples constantes) dans la liste d'arguments NewNameSpace car elles sont conservées en tant qu'expressions qui doivent encore être évaluées. Ainsi, dans votre exemple, print est une expression contenant la définition de la fonction et est réévaluée dans la fonction réelle à chaque utilisation, avant que la fonction réelle puisse s'exécuter. Il fait accomplir votre objectif car il ne crée jamais une variable nommée print contenant une fonction ... juste une expression qui correspond à une fonction.
z = New Namespace(
"z",
f = If( Is Missing( Beep() ), // this is evaluated later, on each access
1,
2
)
);
z:f; // beep!
Je suis d'accord, le message actuel ne devrait pas arriver pour ce cas; J'espère que ça sera réparé.
Améliorer la connaissance du contexte du compilateur JMPQu'est-ce qui a inspiré cette demande de liste de souhaits ?Les messages envoyés au journal peuvent être lents et déroutants pour les utilisateurs
Quelle est l’amélioration que vous souhaiteriez voir ?Ne submergez pas le journal de messages inutiles
Pourquoi cette idée est-elle importante ?C'est plutôt une nuisance, en fait.
Considérez le JSL suivant : j'attache une fonction au nom "print" dans un espace de noms personnalisé.
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???" )
)
Pourquoi est-ce que je reçois cet avertissement ?Je n'essaie pas d'écraser un Builtin.Je sais que je mets le nom dans un espace de noms et c'est ainsi que j'accéderai à la valeur détenue par ce nom.
Le compilateur JMP peut-il savoir quand le nom se trouve dans un espace de noms et ne pas envoyer ces messages au journal ?J'utilise des espaces de noms pour créer des classes personnalisées, donc chaque fois qu'une nouvelle instance est créée, elle spammera le journal avec ces messages superflus.
Automatisation et scriptsRe: Améliorer la prise en compte du contexte du compilateur JMP - Statut modifié en : Reconnu
