Global object instance?

[Sean O'Dell]

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:pen("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:ush(NewGlobal.new)

print("this gets captured\n)

.... then return to the previous context:

Global:op


Kind of a nutty idea, maybe?

Sean O'Dell

 

[Gavin Sinclair]

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

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

 

[Ben Giddings]

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.

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

 

[Aredridel]

--=-9q3FSpKbQpTcKffpCQpU
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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

--=-9q3FSpKbQpTcKffpCQpU
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQA/YeNztP09exA3hooRArcHAKDBLRzoqOeatkBaF27X413uvuERgQCfamXl
CMl0Jl380q0cIh4ZIn/dYe4=
=9c+B
-----END PGP SIGNATURE-----

--=-9q3FSpKbQpTcKffpCQpU--

 

[Bill Kelly]

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

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