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.
I never use eval, exec, exit, fork, sleep, system, throw, or catch.
I did miss require, p, and proc – but I rarely use proc, at that.
Again, those, these are items that have been made “class methods” on
module Kernel. This (in terms of what has happened) raises them to
public visibility.
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.
Sorry, but you read what I wrote incorrectly. “Defined by the Ruby
maintainers as publicly accessible through Kernel::” and “defined by
an individual user.” You can certainly make a private method a
public class method, if you want to.
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.
- What built-in method? Perhaps you’ve chosen the wrong method.
- If it’s not built in, why aren’t you boxing it yourself?
-austin
···
On Friday 28 May 2004 13:02, Austin Ziegler wrote:
–
austin ziegler * austin.ziegler@evault.com