Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Ruby > Global object instance?

Reply
Thread Tools

Global object instance?

 
 
Sean O'Dell
Guest
Posts: n/a
 
      09-11-2003
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

 
Reply With Quote
 
 
 
 
Gavin Sinclair
Guest
Posts: n/a
 
      09-12-2003
> 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




 
Reply With Quote
 
 
 
 
Ben Giddings
Guest
Posts: n/a
 
      09-12-2003
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



 
Reply With Quote
 
Aredridel
Guest
Posts: n/a
 
      09-12-2003

--=-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/YeNztP09exA3hooRArcHAKDBLRzoqOeatkBaF27X413uvuERgQ CfamXl
CMl0Jl380q0cIh4ZIn/dYe4=
=9c+B
-----END PGP SIGNATURE-----

--=-9q3FSpKbQpTcKffpCQpU--


 
Reply With Quote
 
Bill Kelly
Guest
Posts: n/a
 
      09-12-2003
Hi,

From: "Ben Giddings" <(E-Mail Removed)>
[...]
> 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



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Are global functions methods of the global object? User1014 Javascript 3 12-01-2006 01:02 PM
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 1 10-25-2006 06:50 PM
FWSM/PIX and Dynamic PAT using global IP range vs. global interface vs. global IP Hoffa Cisco 0 10-25-2006 01:04 PM
Object creation - Do we really need to create a parent for a derieved object - can't the base object just point to an already created base object jon wayne C++ 9 09-22-2005 02:06 AM
Global Error handling in Applicatio_Error() of Global.asax VSK ASP .Net 1 07-29-2003 03:12 AM



Advertisments