Re: Global object instance?

Gavin Sinclair wrote:

>>I'm thinking, why do we have globals at all?  I wonder if it would be
>>possible to just corral all the "global" stuff (methods, variables,
>>etc.) and just assign all that to a top-level object instance and use
>>that object as the default "global context?"
>>
>>I'm thinking: no fixed global context at all.  Just an object instance
>>that acts as the global context.
>>
>>[.................]
>>
>>Kind of a nutty idea, maybe?
> 
> Kinda nutty, yeah :)
> 
> The example you presented (and others of its ilk) are easily implemented
> in ruby with no inelegance.  Besides, it's bad form to be modifying the
> behavious of global functions.

Well, what I was hoping for was a way to do it WITHOUT modifying the 
behavior, if that's possible.  Aside from details (of which I'm not 
expert enough to enumerate) which inhibit doing this, my thought was to 
make it so this could happen WITHOUT breaking any existing code out there.

> The point is, really, that Kernel contains a bunch of useful methods, as
> well as some that are, frankly, a relic of the past (open, sub).  They
> manage no state; they just do stuff.  It's a convenient and harmless way
> of adding regular features to the language (e.g. loop, puts, throw, catch)
> while keeping the core language simple, as well as exposing necessary
> "kernel" services (local_variables, callcc, syscall).

Yeah, and that wouldn't change.  All I meant to change was where Ruby 
"looked" to get those functions.  All that stuff would still be in 
Kernel, but instead of Ruby looking directly to Kernel by default, it 
would look to the global object, which would have "mixin"'d the Kernel 
module, thereby making all of Kernel's functionality available to the 
default global object, making all existing code out there JustWork(tm).

> Therefore, there's no need to feel like "something ought to be done" about
> Kernel.  It's not on par with global variables.
> 
> But what _did_ catch my attention with your post was the idea that global
> _variables_ might be better wrapped in a class called Global.  But it
> wouldn't make enough purity difference to justify the hassle, IMO.

I'm not much of a purity person, although I do try and never use actual 
$globals.  Instead, I usually wrap EVERYTHING I code into a top-level 
module which contains @variables that sort of act like globals.  The 
difference is when I interact with other code I've written that is not 
part of the application's namespace, it doesn't have access to my main 
namespace @variables.  This is an anti-global discipline, I think.

One use for this would be with mod_ruby.  One of its pitfalls is that 
every scrap of code executed has access to everything in the global 
namespace of every other scrap of code executed.  Virtual hosting is a 
monster issue because of that; security is nil between clients with it. 
  By being able to switch the global context on-the-fly, mod_ruby could 
forcibly switch the context, depending on which host was executing code, 
and in so doing protect clients from one another.

Another use could be for running concurrent Ruby applications in the 
same engine instance.  You could fire up webbrick in one thread with one 
global context object, and test your web client application by 
connecting to it from another thread which has its own global context.

It could also be a way to "eval" code and be absolutely certain it 
doesn't modify your original environment.

It would be nice, anyway ... however difficult it might be.

	Sean O'Dell