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]
