Bonsoir.
Après discution avec Menz pour bien comprendre le problème, je trouve ca logique.
En effet il faut bien différencier les 2 fonctions :
"variable vartest" qui déclare une variable dans le namespace courant
"set vartest 1" qui affecte une valeur a une variable
Ainsi de la même facon qu'il est utile d'appeler des variables globales dans un namespace, par exemple :
il n'est pas illogique de pouvoir les manipuler en écriture :
Dans les 2 cas, le bot va voir qu'aucune variable "version" n'a été déclarée au niveau du namespace courant et donc regarder au niveau du namespace global.
Le problème n'est donc pas la portabilité de la variable mais bien la déclaration implicite des variables par la fonction "set" lorsque celles-ci n'existent pas qui nous facilite trop la vie et empêche d'être vigilant sur la pré-existence de certaines variables au niveau global.
Je suppose que comme d'habitude je ne suis pas clair mais Menz saura j'en suis sûr expliquer mon point de vue ; en tout cas, je ne trouve ce comportement tout à fait normal.
Après, l'accessibilité et la modification de n'importe qu'elle variable de n'importe quel namespace depuis n'importe quel namespace me parait incohérent et dangereux mais il parait que ca fait partie de la philosophie des eggdrop...
PS : la ligne
ne fonctionne pas car la variable version est protégée mais c'était pour que tout le monde comprenne l'exemple (ou pas)
Après discution avec Menz pour bien comprendre le problème, je trouve ca logique.
En effet il faut bien différencier les 2 fonctions :
"variable vartest" qui déclare une variable dans le namespace courant
"set vartest 1" qui affecte une valeur a une variable
Ainsi de la même facon qu'il est utile d'appeler des variables globales dans un namespace, par exemple :
tcl
namespace eval testnamespace { putlog "$version" }
il n'est pas illogique de pouvoir les manipuler en écriture :
tcl
.tcl namespace eval testnamespace { set version 3}
Dans les 2 cas, le bot va voir qu'aucune variable "version" n'a été déclarée au niveau du namespace courant et donc regarder au niveau du namespace global.
Le problème n'est donc pas la portabilité de la variable mais bien la déclaration implicite des variables par la fonction "set" lorsque celles-ci n'existent pas qui nous facilite trop la vie et empêche d'être vigilant sur la pré-existence de certaines variables au niveau global.
Je suppose que comme d'habitude je ne suis pas clair mais Menz saura j'en suis sûr expliquer mon point de vue ; en tout cas, je ne trouve ce comportement tout à fait normal.
Après, l'accessibilité et la modification de n'importe qu'elle variable de n'importe quel namespace depuis n'importe quel namespace me parait incohérent et dangereux mais il parait que ca fait partie de la philosophie des eggdrop...
PS : la ligne
tcl
".tcl namespace eval testnamespace { set version 3} "ne fonctionne pas car la variable version est protégée mais c'était pour que tout le monde comprenne l'exemple (ou pas)