If you start using Modules (and Classes) than you’re probably
after an OO design. Why would you then put things as “global” and
not in a dedicated namespace/class? The only time you may
want to do this is when you need it from within each object (or
for convenience, like Kernel). If you want to break this
paradigm, Ruby lets you do this by calling the TOPLEVEL_BINDING.
I didn’t put this particular method in the global space. It’s in
one of the built-in libraries.
If it’s one of the built-ins, then it’s probably in Kernel:
class Foo
def test(*args)
p “in foo::test”
end
def bar(file)
Kernel.test(?A, file)
end
end
Foo.new.bar
Besides, you should be able to have globals, even if you partition
your code into namespaces.
It generally indicates bad design when that’s the case in an OO
project.
-austin
···
On Thursday 27 May 2004 22:34, Mehr, Assaph (Assaph) wrote:
–
austin ziegler * austin.ziegler@evault.com
If you start using Modules (and Classes) than you’re probably
after an OO design. Why would you then put things as “global” and
not in a dedicated namespace/class? The only time you may
want to do this is when you need it from within each object (or
for convenience, like Kernel). If you want to break this
paradigm, Ruby lets you do this by calling the TOPLEVEL_BINDING.
I didn’t put this particular method in the global space. It’s in
one of the built-in libraries.
If it’s one of the built-ins, then it’s probably in Kernel:
It’s not, I tried that.
It generally indicates bad design when that’s the case in an OO
project.
The nomeclature for a global namespace changes from language to language, but
the concept is generally the same, and it’s not an indicator of bad design.
Globals, like the infamous goto, have uses. In the wrong hands, they can
cause problems, but in the right hands, they can solve them.
Sean O'Dell
···
On Friday 28 May 2004 11:49, Austin Ziegler wrote:
On Thursday 27 May 2004 22:34, Mehr, Assaph (Assaph) wrote: