Oggetto: miglioramento della consapevolezza del contesto del compilatore JMP - Stato modificato in: RiconosciutoGrazie per l'input. Desideriamo informare l'utente quando sta potenzialmente sovrascrivendo una funzione JMP principale. Posso vedere come questo potrebbe essere fastidioso per un utente più esperto. Condivideremo questo con il nostro team di sviluppo e vedremo se possiamo fornire un modo per sopprimere i messaggi di avviso come questo. La sfida sarà come determinare quali messaggi di avviso dovrebbero o potrebbero essere soppressi.
Suppongo che se stessi definendo funzioni come questa più e più volte, il registro potrebbe essere riempito. Con quale frequenza lo vedi accadere nei tuoi script e nei file di registro associati? Inoltre, definire la funzione in modo diverso impedirebbe questo tipo di messaggio nel registro, ad es
"test namespace":customprint=Function({}, "will this print?");
Oggetto: miglioramento della consapevolezza del contesto del compilatore JMP - Stato modificato in: IndagineOggetto: migliorare la consapevolezza del contesto del compilatore JMPGrazie per la tua risposta - non è troppo fastidioso - è quando AddinLoad viene eseguito e le mie classi vengono inizializzate - ho cambiato i generatori di istanze per utilizzare il metodo seguente per evitare di inserire questi messaggi nel registro per ogni nuova istanza.
Quindi, se è qualcosa che è facile da fare da parte tua, sarebbe piuttosto carino, ma non è affatto una priorità assoluta.
new namespace( "test",
{
print = Function( {},
show( "test" )
)
}
);
"test":print;Oggetto: migliorare la consapevolezza del contesto del compilatore JMPCredo che questa sia una soluzione migliore:
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
Non mi piace aggiungere dichiarazioni di assegnazione (diverse da semplici costanti) nell'elenco di argomenti di NewNameSpace perché sono mantenute come espressioni che devono ancora essere valutate. Quindi, nel tuo esempio, print è un'espressione che contiene la definizione della funzione e viene rivalutata nella funzione effettiva ad ogni utilizzo, prima che la funzione effettiva possa essere eseguita. Esso fa raggiungere il tuo obiettivo perché non crea mai una variabile denominata print che contiene una funzione ... solo un'espressione che valuta una funzione.
z = New Namespace(
"z",
f = If( Is Missing( Beep() ), // this is evaluated later, on each access
1,
2
)
);
z:f; // beep!
Sono d'accordo, il messaggio corrente non dovrebbe verificarsi per questo caso; Spero che venga risolto.
Migliora la consapevolezza del contesto del compilatore JMPCosa ha ispirato questa richiesta di lista dei desideri?I messaggi inviati al registro possono essere lenti e creare confusione per gli utenti
Qual è il miglioramento che vorresti vedere?Non inondare il log con messaggi inutili
Perché questa idea è importante?È più un fastidio, davvero.
Considera il seguente JSL: allego una funzione al nome "stampa" all'interno di uno spazio dei nomi personalizzato.
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???" )
)
Perché ricevo questo avviso?Non sto cercando di sovrascrivere un file Builtin.So che sto inserendo il nome all'interno di uno spazio dei nomi e questo è il modo in cui accederò al valore contenuto in quel nome.
Il compilatore JMP può essere consapevole di quando il nome si trova all'interno di uno spazio dei nomi e non inviare questi messaggi al registro?Utilizzo gli spazi dei nomi per creare classi personalizzate, quindi ogni volta che viene creata una nuova istanza invierà spam al registro con questi messaggi superflui.
Automazione e scriptingRe: Migliorare la consapevolezza del contesto del compilatore JMP - Stato modificato in: Riconosciuto
