Global object instance?

ruby-talk
1

I’m thinking, why do we have globals at all? I wonder if it would be
possible to just corral all the “global” stuff (methods, variables,
etc.) and just assign all that to a top-level object instance and use
that object as the default “global context?”

I’m thinking: no fixed global context at all. Just an object instance
that acts as the global context.

By default, you could “mixin” the Kernel module and that would take care
of most the backwards compatibility issues, eh? If not, hopefully you
could mixin other modules to finish the job.

One advantage I’m thinking of is that you could re-assign the global
context to be any object instance, and all global-style references
($variables, ::methods()), would then refer to the new object.

So if you had:

class NewGlobal
include Kernel

 def initialize
   @stdout = File::open("capture.txt",
     File::RDWR|File::TRUNC|File::CREAT)
 end

end

… in one call, you could print to the console:

print("this goes to the screen\n)

… then you could switch things up:

Global::push(NewGlobal.new)

print("this gets captured\n)

… then return to the previous context:

Global::pop

Kind of a nutty idea, maybe?

Sean O'Dell
2

I’m thinking, why do we have globals at all? I wonder if it would be
possible to just corral all the “global” stuff (methods, variables,
etc.) and just assign all that to a top-level object instance and use
that object as the default “global context?”

I’m thinking: no fixed global context at all. Just an object instance
that acts as the global context.

[…]

Kind of a nutty idea, maybe?

Sean O’Dell

Kinda nutty, yeah :slight_smile:

The example you presented (and others of its ilk) are easily implemented
in ruby with no inelegance. Besides, it’s bad form to be modifying the
behavious of global functions.

The point is, really, that Kernel contains a bunch of useful methods, as
well as some that are, frankly, a relic of the past (open, sub). They
manage no state; they just do stuff. It’s a convenient and harmless way
of adding regular features to the language (e.g. loop, puts, throw, catch)
while keeping the core language simple, as well as exposing necessary
“kernel” services (local_variables, callcc, syscall).

Therefore, there’s no need to feel like “something ought to be done” about
Kernel. It’s not on par with global variables.

But what did catch my attention with your post was the idea that global
variables might be better wrapped in a class called Global. But it
wouldn’t make enough purity difference to justify the hassle, IMO.

Gavin

3

Gavin Sinclair wrote:

I’m thinking, why do we have globals at all? I wonder if it would be
possible to just corral all the “global” stuff (methods, variables,
etc.) and just assign all that to a top-level object instance and use
that object as the default “global context?”

I’m thinking: no fixed global context at all. Just an object instance
that acts as the global context.

[…]

Kind of a nutty idea, maybe?

Kinda nutty, yeah :slight_smile:

The example you presented (and others of its ilk) are easily implemented
in ruby with no inelegance. Besides, it’s bad form to be modifying the
behavious of global functions.

Well, what I was hoping for was a way to do it WITHOUT modifying the
behavior, if that’s possible. Aside from details (of which I’m not
expert enough to enumerate) which inhibit doing this, my thought was to
make it so this could happen WITHOUT breaking any existing code out there.

The point is, really, that Kernel contains a bunch of useful methods, as
well as some that are, frankly, a relic of the past (open, sub). They
manage no state; they just do stuff. It’s a convenient and harmless way
of adding regular features to the language (e.g. loop, puts, throw, catch)
while keeping the core language simple, as well as exposing necessary
“kernel” services (local_variables, callcc, syscall).

Yeah, and that wouldn’t change. All I meant to change was where Ruby
“looked” to get those functions. All that stuff would still be in
Kernel, but instead of Ruby looking directly to Kernel by default, it
would look to the global object, which would have “mixin”'d the Kernel
module, thereby making all of Kernel’s functionality available to the
default global object, making all existing code out there JustWork™.

Therefore, there’s no need to feel like “something ought to be done” about
Kernel. It’s not on par with global variables.

But what did catch my attention with your post was the idea that global
variables might be better wrapped in a class called Global. But it
wouldn’t make enough purity difference to justify the hassle, IMO.

I’m not much of a purity person, although I do try and never use actual
$globals. Instead, I usually wrap EVERYTHING I code into a top-level
module which contains @variables that sort of act like globals. The
difference is when I interact with other code I’ve written that is not
part of the application’s namespace, it doesn’t have access to my main
namespace @variables. This is an anti-global discipline, I think.

One use for this would be with mod_ruby. One of its pitfalls is that
every scrap of code executed has access to everything in the global
namespace of every other scrap of code executed. Virtual hosting is a
monster issue because of that; security is nil between clients with it.
By being able to switch the global context on-the-fly, mod_ruby could
forcibly switch the context, depending on which host was executing code,
and in so doing protect clients from one another.

Another use could be for running concurrent Ruby applications in the
same engine instance. You could fire up webbrick in one thread with one
global context object, and test your web client application by
connecting to it from another thread which has its own global context.

It could also be a way to “eval” code and be absolutely certain it
doesn’t modify your original environment.

It would be nice, anyway … however difficult it might be.

Sean O'Dell
4

Sean O’Dell wrote:

I’m not much of a purity person, although I do try and never use actual
$globals. Instead, I usually wrap EVERYTHING I code into a top-level
module which contains @variables that sort of act like globals. The
difference is when I interact with other code I’ve written that is not
part of the application’s namespace, it doesn’t have access to my main
namespace @variables. This is an anti-global discipline, I think.

I’m often too much of a purity person, because of that, I’ve been using
singletons instead of globals. You might like this solution so let me
explain.

I have a bunch of configuration parameters for something I wrote. There
are 5 main files, each of which contains a class which encapsulates some
behaviour. A 6th file is also around which can run any of the other 5
tasks in the correct order. There is some configuration data that
different classes all use.

What I do is I wrap all those variables in a “Config” object. The first
time it is needed it is created, and its state is loaded from a config
file. It is a singleton, so each class has in its constructor: @conf =
Config.instance. If it didn’t yet exist, it is created and initialized
here, otherwise the existing singleton is simply returned. Then when I
need a config setting I just use: “days = @conf.num_days”.

I don’t use any globals, so I don’t need to worry about naming clashes,
and because of the way singletons work, I always know that my objects
are all sharing the same data.

Gavin Sinclair wrote:

The point is, really, that Kernel contains a bunch of useful methods, as
well as some that are, frankly, a relic of the past (open, sub). They
manage no state; they just do stuff. It’s a convenient and harmless way
of adding regular features to the language (e.g. loop, puts, throw,
catch)
while keeping the core language simple, as well as exposing necessary
“kernel” services (local_variables, callcc, syscall).

While we’re on the subject, I’m curious how many people use the Kernel
version of certain methods, rather than the associated object version.

How many people use:
chomp() vs String#chomp()
chop() vs String#chop()
gsub() vs String#gsub()
open() vs IO#popen()/File#open()
gets(), readline(), readlines() vs something using File
scan() vs String#scan()
select() vs IO.select()
split() vs String#split()
sub() vs String#sub()
test() vs Filetest stuff

If most people don’t use these, I think it would be good to migrate them
out of the language. There are many useful kernel methods that should
stick around. I much prefer using puts to $stdout.puts(), but I
really think the String stuff that works on $_ should go. Any thoughts?

Ben

5

How many people use:
chomp() vs String#chomp()
chop() vs String#chop()
gsub() vs String#gsub()

I don’t think I ever use thse.

open() vs IO#popen()/File#open()
gets(), readline(), readlines() vs something using File
scan() vs String#scan()

These only when doing one-off sysadmin scripts – but that’s very good
for quick and dirty, so I think they should stay.

select() vs IO.select()

Always use this variant from kernel.

split() vs String#split()
sub() vs String#sub()

Never

test() vs Filetest stuff

In quick scripts.

Honestly, I like most of them, but they’re always for quick and dirty
stuff except select, which for some reason seems low-level to me.

Ari

6

Hi,

[…]

There are many useful kernel methods that should
stick around. I much prefer using puts to $stdout.puts(), but I
really think the String stuff that works on $_ should go. Any thoughts?

I strongly disagree. Removing these would mean I’d have to
keep my Perl skills honed, which is something I’ve been glad
to be able to let fade away… :slight_smile:

Here are two Ruby one-liners I used just yesterday:

ruby -i -pe ‘gsub(/#!\Perl\bin\perl.exe/, “#!/usr/bin/perl”)’ *.cgi

ruby -i -pe ‘gsub(/\015/, “”)’ *.cgi *.html *.pm *.txt

Something I love about Ruby is that, in addition to everything
else it does well, it still lets me write powerful simple one-
liners from the command line.

(The one-liners above presumably need no explanation, but the
context was we were installing a package containing a lot of
Perl CGI scripts that had been developed on Windows, and they
needed some conversion–line endings, shebang line–in order
to work on Linux… I.e. the point is not that there’s
anything special about these specific one-liners… Just that
it’s so easy to craft them in Ruby… If it weren’t, I’d have
to go back to using Perl for such things… And I wouldn’t like
that…)

Regards,

Bill

···

From: “Ben Giddings” bg-rubytalk@infofiend.com