From: Austin Ziegler <Austin.Ziegler@...>
Date: 2004-05-29T05:41:38+09:00
Subject: Re: Calling global method

> On Friday 28 May 2004 13:02, Austin Ziegler wrote:
>>>> 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.

1. What built-in method? Perhaps you've chosen the wrong method.
2. If it's not built in, why aren't you boxing it yourself?

-austin
--
austin ziegler * austin.ziegler@evault.com