Sharing variables across methods

[David Garamond]

When writing short scripts (several pages long) I often want to share
some variables (like CGI object, DB connection object) in several
methods. I often use globals for this:

$cgi = CGI.new('html3')
$conn = PGconn.connect(...)

def foo
$conn.exec(...)
$cgi.out { ... }
end

When I don't want to see all those dollar signs, I use a wrapper method:

$_cgi = CGI.new('html3')
def cgi; $_cgi end

def foo
cgi.out { ... }
end

But it still looks ugly to me. Any suggestion to make it more elegant?

 

[Mohammad Khan]

When writing short scripts (several pages long) I often want to share
some variables (like CGI object, DB connection object) in several
methods. I often use globals for this:

$cgi = CGI.new('html3')
$conn = PGconn.connect(...)

def foo
$conn.exec(...)
$cgi.out { ... }
end

When I don't want to see all those dollar signs, I use a wrapper method:

$_cgi = CGI.new('html3')
def cgi; $_cgi end

def foo
cgi.out { ... }
end

But it still looks ugly to me. Any suggestion to make it more elegant?

How about to keep all your methods in a module or class.
And use accessors.

 

[Jamis Buck]

When writing short scripts (several pages long) I often want to share
some variables (like CGI object, DB connection object) in several
methods. I often use globals for this:

$cgi = CGI.new('html3')
$conn = PGconn.connect(...)

def foo
$conn.exec(...)
$cgi.out { ... }
end

When I don't want to see all those dollar signs, I use a wrapper method:

$_cgi = CGI.new('html3')
def cgi; $_cgi end

def foo
cgi.out { ... }
end

But it still looks ugly to me. Any suggestion to make it more elegant?

For really short scripts, I usually pass the "globals" as parameters to
the methods. If the scripts get long enough, to where that's an
annoyance, I take that as a hint that its time to add some classes.
Then, what used to be globals become instance variables of the class,
and you can use "attr_reader" to easily create your accessor methods for
you (if the '@' sigil bothers you).

- Jamis

 

[Mohammad Khan]

Is it possible to unsubscribe from a thread?

I would like to receive every posting in my mailbox.
If I found myself that I am not interested in a particular thread, I
will have an option to unsubscribe from that thread.

I hope, I could explain properly.


Thanks,

 

[Ara.T.Howard]

When writing short scripts (several pages long) I often want to share
some variables (like CGI object, DB connection object) in several
methods. I often use globals for this:

$cgi = CGI.new('html3')
$conn = PGconn.connect(...)

def foo
$conn.exec(...)
$cgi.out { ... }
end

When I don't want to see all those dollar signs, I use a wrapper method:

$_cgi = CGI.new('html3')
def cgi; $_cgi end

def foo
cgi.out { ... }
end

But it still looks ugly to me. Any suggestion to make it more elegant?

what you are saying is that you want something that shares state and methods -
this is a perfect oportunity to create a class:

class CGIApp
def initialize opts = {}
@cgi = CGI::new 'html3'
@pgconn = PGconn::connect(*opts['pgconn'])
end
def foo
@pgconn.exec ...
@cgi.out ...
end
end

if you also need a global handle on the object created and, like in this case,
there can be only one of them extent at a time, you can hang some class
methods of the class to retrive the object - for instance use the multiton
pattern:

class CGIApp
class << self
attr :instance
def new(*a,&b); @instance ||= super; end
end
end

kind regards.

-a
--
===============================================================================
| EMAIL :: Ara [dot] T [dot] Howard [at] noaa [dot] gov
| PHONE :: 303.497.6469
| When you do something, you should burn yourself completely, like a good
| bonfire, leaving no trace of yourself. --Shunryu Suzuki
===============================================================================

 

[Austin Ziegler]

Is it possible to unsubscribe from a thread?

I would like to receive every posting in my mailbox.
If I found myself that I am not interested in a particular thread, I
will have an option to unsubscribe from that thread.

I hope, I could explain properly.

Thanks,

Are you referring to ruby-forum or ruby-talk?

-austin

 

[Mohammad Khan]

r

Are you referring to ruby-forum or ruby-talk?

ruby-talk

-austin

 

[David Garamond]

How about to keep all your methods in a module or class.
And use accessors.

I should stress that this is for *short* scripts I don't want to
define any module or class like I would have to in Java. But yes, in a
class I would just use attr_{reader|accessor}.

 

[Austin Ziegler]

ruby-talk

Then, no, not really.

What you can do is add a filter to your client to kill that thread
(mark it read, delete it, whatever). This will vary by each client and
is easier to do in those clients that do double duty as newsreaders
(e.g., Outlook Express, Mozilla Thunderbird, etc.).

-austin

 

[Mohammad Khan]

Then, no, not really.

What you can do is add a filter to your client to kill that thread
(mark it read, delete it, whatever). This will vary by each client and
is easier to do in those clients that do double duty as newsreaders
(e.g., Outlook Express, Mozilla Thunderbird, etc.).

-austin

But problem is, after 1 or 2 months I might end up with 100+ filters in
my mail client !!

 

[Austin Ziegler]

But problem is, after 1 or 2 months I might end up with 100+ filters in
my mail client !!

That's the way email works, though :/

Alternatively, you can read comp.lang.ruby (which is mirrored with
ruby-talk, apparently 100% now) and then you can mark threads as
"ignored" and that will get about 90% of the threads you want ignored
ignored. This doesn't really add much weight.

-austin

 

[Bill Atkins]

So just use the newsgroup interface at groups.google.com.

Or just suck it up and delete the messages you don't want.

Bill

 

[Mohammad Khan]

So just use the newsgroup interface at groups.google.com.

Or just suck it up and delete the messages you don't want.

Bill

How about this?
If you reply with "Unsubscribe Thread" at the first line of Body, would
unsubscribe you from the thread !!

 

[Austin Ziegler]

How about this?
If you reply with "Unsubscribe Thread" at the first line of Body, would
unsubscribe you from the thread !!

Unfortunately, there are two problems with this:

(1) this would massively increase the workload of the mailing list
server, having to keep track of individual client preferences; it's
worse because there are people subscribed from more than one location
(as I was, for a while), because then you either have to coordinate
these or have even more workload.

(2) there is no standard definition of "thread". Is it subject-based
(common, but sometimes wrong), message-ID based (very common, but also
occasionally wrong or misused -- and some mail agents don't actually
do what they should do with this).

This is properly a client-side issue.

-austin

 

[Mohammad Khan]

Unfortunately, there are two problems with this:

(1) this would massively increase the workload of the mailing list
server, having to keep track of individual client preferences; it's
worse because there are people subscribed from more than one location
(as I was, for a while), because then you either have to coordinate
these or have even more workload.

(2) there is no standard definition of "thread". Is it subject-based
(common, but sometimes wrong), message-ID based (very common, but also
occasionally wrong or misused -- and some mail agents don't actually
do what they should do with this).

This is properly a client-side issue.

-austin

I agree with you on both issue you pointed out.

The reason, I unsubscribed from MySQL list was:
I was getting to many mails that I was not able to control them and also
there had very few mails I was interested in.

I am not very much dedicated in any forum like many unlike few.
Can you imagine what will happen after 1 year or future.
There will have more dedicated people in the forum than less dedicated
people like me. I don't expect it as a ruby programmer.

I am just trying to see this issue a new rubyist.

 

[Robert Klemme]

When writing short scripts (several pages long) I often want to share
some variables (like CGI object, DB connection object) in several
methods. I often use globals for this:

$cgi = CGI.new('html3')
$conn = PGconn.connect(...)

def foo
$conn.exec(...)
$cgi.out { ... }
end

When I don't want to see all those dollar signs, I use a wrapper method:

$_cgi = CGI.new('html3')
def cgi; $_cgi end

def foo
cgi.out { ... }
end

But it still looks ugly to me. Any suggestion to make it more elegant?

Personally I'd leave the globals in (with "$") - using these accessor
methods rather obscures what's happening. If you use those accessors then
maybe instance variables are more suited. That way you might be able to
later migrate the script into a class - which is probably the best thing
anyway if it gets more complex (command pattern comes to mind).

Kind regards

robert

 

[Jim Weirich]

I am not very much dedicated in any forum like many unlike few.
Can you imagine what will happen after 1 year or future.
There will have more dedicated people in the forum than less dedicated
people like me. I don't expect it as a ruby programmer.

I am just trying to see this issue a new rubyist.

This is a valid concern, for ruby-talk has become a virtual torrent of
postings lately. I think this is a *good* thing, but it does really put
the strain on the readers. Shoot, even I have trouble keeping up.

Perhaps someone would be interested in publishing a weekly summary of
interesting threads in the list. Post the summary regularly with
pointers back to the ruby-talk archive so that someone reading the
digest could peruse just the threads that sounded interesting.

Other than that, getting a good mail client that supports some level of
threading really helps out too. (I used to use GNUS to read mail and
that could score messages according to user defined criteria. I wish my
current mail client did that.)