Jonne Zutt wrote: > Damn, I followed your advice and starting adding global's, instead of > modifying var to ::var. However, after deleting all changes I made > yesterday (silly me :@) and adding several global's, I figured out > that does not work. > > The idea of the tip apparently is that the global and variable > commands will disappear. Global will not have any effect anymore. > Where a variable is stored can be seen completely from the variable > name.
No - 'global' and 'variable' will stay. Where did you get that from? There is actually another tip that looks to specifying currently unspecified behaviour for them (http://www.tcl.tk/cgi-bin/tct/tip/276), but that is irrelevant to TIP 278. In terms of clarity, maintainability and performance, the variable linking commands (global, variable, upvar, the new namespace upvar) are possibly the best choice. >> but I'd like to suggest something.. instead of doing $::varname I >> think it would be best to use global varname; $varname ...and >> especially for namespace vars.. the reason imagine you have a >> namespace MSN { $::MSN::protocol_version } and now we add multi >> protocol and we want namespace ::protocols::MSN { >> $::protocols::MSN::protocol_version } ... well, if we have hundreds >> of vars everywhere, we'd need to replace each one.. with 'variable' >> we won't need to... Right: the maintainability issue I hinted at above. > We should use relative names as much as possible. That way your above > remark is still valid. But as for the initialize_amsn, it really > must become ::initialize_amsn, there's no other way. Or else (just showing, not suggesting in this particular case as it is possibly overkill for a var that will not be used very often): # Some config file somewhere set ::moduleNS ::some::deep::namespaced::module # much later, maybe some sourced file namespace eval $::moduleNS { upvar #0 initialize_amsn init proc reinit {} {variable init; ...; set init(thisModule) 1} if {!$init(thisModule)} reinit ... } > When using relative names, we can add "variable varname" so that it > works right now as well, and I can already commit those. Yes, that is the way to go if it is a relative name starting at [namespace current]. % namespace eval a { namespace eval b {variable x 1} proc w {} {variable b::x; set x} } % a::w 1 What I think is the best is: for variables that are to be used more than once or twice, just link them to some local var using global, variable, upvar or namespace upvar. Then address the local var - it works as an alias. As illustrated above. The advantages are: clarity (no $::long::name::chains::to::simplevar, just $simplevar), speed (access to linked vars is very fast, faster than fully qualified names), maintainability (if you change a namespace path, you do not have it all over the place). HTH. Miguel PS1: guys, thanks for doing this with so much energy! As you are doing the cleanup, I'd love to know how much had to be changed in the end. PS2: those suggestions there should be interpreted as expressing my personal preference - aesthetics and all that. De gustibus non est disputandum :) ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Amsn-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/amsn-devel
