After chatting with Karl a bit, I think my plan is to add a new command called
reqvar that can be used as a way of getting a local variable from the ::request
namespace. We'll leave the ::request::global command in for now, but I think
it's a hack and needs to probably get removed. If people want a global, you
global it. If you want a namespace variable, you variable. You want a
"request" variable, reqvar.
Any objections?
D
On Sep 9, 2010, at 7:43 PM, Karl Lehenbauer wrote:
> Absolutely you can leave truly global variables laying around, it's valuable,
> and this is an important capability of Rivet. We get around the problem
> you're talking about by using toplevel namespaces for the procs and variables
> of our packages.
>
> We load up tons of truly global variables in our Rivet child init script,
> arrays that function as a cache for airport names, city names, aircraft
> types, all sorts of stuff. We've moved to message catalogs for a lot of that
> stuff now, using speedtables and PostgreSQL, but we did it that way for years
> and still have lots of global stuff that pages expect and rely on.
>
> Anyway...
>
> So if you "package require foo" then the foo package is wrapped in a
> "namespace eval ::foo {}" and it won't recompile any compiled procs for
> subsequent pages. We don't put procs in the .rvt pages, that is we try to
> avoid it if there is any reusability possible at all, it goes into a package.
>
> When we want real global variables we use the ::var notation or we invoke
> ::global instead of global.
>
> I think it needs to stay the way it works now and the way it works is fine
> and you just need to scale up your approach by loading all your reusable
> stuff outside of ::request, even pulled in in your child init script but
> that's not required.
>
> As long as you use packages and the stuff is in namespaces, it's all money.
> And tcllib and all that stuff work that way, most stuff works that way, so
> you don't get screwed by third party packages very much either.
>
> There's also that rivet cache dealie where you can say oh cache the last 200
> compiled pages, so you might look at that too. Also I bet you can define
> your procs globally with something like "proc ::foo" if you want to just
> shotgun it.
>
> On Sep 9, 2010, at 7:06 PM, Damon Courtney wrote:
>
>> 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]
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
