So, way back when we first wrote Rivet, we had this bright idea to make a ::request::global command that automatically forced "global" variables into the ::request namespace so that users could say
global foo And get what was EFFECTIVELY a global variable for their request but without actually setting something in the global namespace that would hang around between requests. It seemed like a good idea at the time. 0-] Now that I'm doing more Rivet development, this is looking like maybe a bad idea. Not that we need to take out what is already there (it's already been in use for a while), but I think we need something better and a little more specific to what we're doing. My problem is this. I have a source file of code that is getting sourced every time a request comes in, and it's re-compiling my procs every time because the request namespace got blown away from the last request. Instead, I want to make my procs in the global namespace but with the ability to scope variables from the ::request namespace so that the procs exist but never actually operate at #0. I could easily do something like: variable ::request::foo within my procs, but that is assuming knowledge of Rivet and knowing that we're operating within a namespace called ::request. I would prefer not to do that. So, my proposal is either to rename Tcl's global out of the way and just make our global hack be the default global, or we create a new command. Something like reqvar (for a request variable) or something. I'm perfectly happy to just rename global to something like ::tcl_global and be done with it. In reality, when the hell would you EVER want a truly global variable to be set from your request? There's absolutely NO guarantee you're ever going to see that variable again, so it seems silly to even allow it. If you REALLY had a need for it, you could just as easily use ::foo and get a globally-scoped variable without the command. Any thoughts or opinions? D --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
