From: Sean O'Dell <sean@...>
Date: 2004-05-29T04:14:57+09:00
Subject: Re: Calling global method

On Friday 28 May 2004 11:56, Austin Ziegler wrote:
> >>S> There really should be a module called global, or
> >>S> perhaps an object named global, that keeps all the global
> >>S> variables and methods. That way you could just call
> >>S> global.method. There should also be syntax sugar to allow you
> >>S> to say ::method.
> >> "global" methods are private : this is why you can't call
> >> Object.test
> >>
> >> svg% ruby -e 'def test() end; p Object.test'
> >> -e:1: private method `test' called for Object:Class (NoMethodError)
> >> svg%
> >
> > Yes, but that's not how globals usually behave. Globals are
> > usually always globally available unless overridden or removed.
>
> Does Ruby *need* globals, especially given that Kernel already
> exists?

Kernel is just another way of saying global.  How you implement globals 
doesn't change the concept of globals itself.  Whether they're held in a 
nameless or named space, they're still globals.

But it seems to me that Kernel ended up being the global namespace after a 
couple paradigm changes, and there isn't much consistency about them.  Some 
globals are private members of Object and some are in Kernel.  You can access 
global variables anywhere using $, but you can't access all global methods 
from anywhere.  You can access Kernel::method globals, if they're in Kernel, 
but if they're a private member of Object, you have to perform some strange 
tricks.

It would be nice of all globals were wrapped up in a Global module, so you 
could access them directly from anywhere.  Variables could still be sugared 
with $, and methods could be sugared with ::.

	Sean O'Dell