Calling global method

ruby-talk
1

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.

shrug I find that, with the exception of three methods I use
almost as keywords (block_given?, puts, raise), I don’t tend to use
what’s in Kernel.

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.

There is consistency, though. If it’s defined as a method in Kernel,
then it’s available “publicly” through Kernel. If it’s defined by
you, the user, then it’s a private member method of the Object
class. Since the execution context of all programs is through an
instance of Object, those items that look like globals aren’t.

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
::.

shrug Again, I don’t find the idea useful.

-austin

···

–
austin ziegler * austin.ziegler@evault.com

2

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.

shrug I find that, with the exception of three methods I use
almost as keywords (block_given?, puts, raise), I don’t tend to use
what’s in Kernel.

You don’t use eval, exec, exit, fork, load, p, proc, require, sleep, system,
throw or catch? I use all of those fairly often.

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.

There is consistency, though. If it’s defined as a method in Kernel,
then it’s available “publicly” through Kernel. If it’s defined by
you, the user, then it’s a private member method of the Object
class. Since the execution context of all programs is through an
instance of Object, those items that look like globals aren’t.

Public through Kernel, private through Object. That’s not consistent to me.
That sounds like a series of decisions that were made without much thought to
previous decisions about where globals go. Of course, it’s tempting to say
that it’s designed this way on purpose, but stepping back and looking at the
design as a whole, it looks kludgy.

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

::.

shrug Again, I don’t find the idea useful.

Well, I find it useful as I’m a bit stuck right now about how to call a global
method without producing some ugly code. It looks like ugly is going to win,
though, since there is no clean built-in way to do it.

Sean O'Dell
···

On Friday 28 May 2004 13:02, Austin Ziegler wrote: