Globals not incrementing inside block

ruby-talk
1

I have the following snippet:

    at_exit do
  $total_count, $daily_count = 0, 0
  IO.foreach(my_logfile) do |line|
      $total_count.next
      $daily_count.next if line =~ /^#{Time.now.strftime('%Y%m%d')}/
  end
  printf("\ns Total: %d\ns Today:%d\n", $total_count,
      $daily_count)
    end

I assumed I had to use globals, since otherwise the block would treat
the counters as local variables, but I have the same problem either way:
the counters never increase. They still both read zero at the end of the
script, even though some strategic puts statements show that the file is
successfully being read.

What newbie mistake am I making now?

···

--
"Oh, look: rocks!"
  -- Doctor Who, "Destiny of the Daleks"

2

$total_count.next does not increment $total_count try this instead:

$total_count += 1

Cheers-

-- Ezra Zygmuntowicz-- Lead Rails Evangelist
-- ez@engineyard.com
-- Engine Yard, Serious Rails Hosting
-- (866) 518-YARD (9273)

···

On Jun 6, 2007, at 6:34 PM, Todd A. Jacobs wrote:

I have the following snippet:

    at_exit do
  $total_count, $daily_count = 0, 0
  IO.foreach(my_logfile) do |line|
      $total_count.next
      $daily_count.next if line =~ /^#{Time.now.strftime('%Y%m%d')}/
  end
  printf("\ns Total: %d\ns Today:%d\n", $total_count,
      $daily_count)
    end

I assumed I had to use globals, since otherwise the block would treat
the counters as local variables, but I have the same problem either way:
the counters never increase. They still both read zero at the end of the
script, even though some strategic puts statements show that the file is
successfully being read.

What newbie mistake am I making now?

--
"Oh, look: rocks!"
  -- Doctor Who, "Destiny of the Daleks"

3

Hi,

···

On Jun 6, 2007, at 6:34 PM, Todd A. Jacobs wrote:

I have the following snippet:

    at_exit do
  $total_count, $daily_count = 0, 0
  IO.foreach(my_logfile) do |line|
      $total_count.next

You're not storing the new value
$total_count = $total_count.next
or
$total_count += 1

Also, you don't need globals to do what you're trying to do.

4

You don't need global variables.

total = 0
5.times do
total += 1
end

p total # 5

Harry

···

On 6/7/07, Todd A. Jacobs <tjacobs-sndr-019fdb@codegnome.org> wrote:

I assumed I had to use globals, since otherwise the block would treat
the counters as local variables, but I have the same problem either way:
the counters never increase. They still both read zero at the end of the
script, even though some strategic puts statements show that the file is
successfully being read.

What newbie mistake am I making now?

--
"Oh, look: rocks!"
        -- Doctor Who, "Destiny of the Daleks"

--

A Look into Japanese Ruby List in English

5

You don't need global variables.

total = 0
5.times do
total += 1
end

Unless you want your snippet to have side effects. Which is unlikely,
since the method is called at_exit. Anyway, you are assigning the
variables new values, so you can use local ones instead.

···

__________________________________________

Dictionary is the only place that success comes before work. - Vince
Lombardi

6

This one is a very common mistake when someone is new to functional
languages specially when having some procedural language experience.
Try looking closer at the Ruby language documentation or at any other
online or book reference.

Many methods in functional languages don't have side effects (don't
modify the object), take this as an example:

string = "beer"

=> "beer"

string.chop

=> "bee"

string

=> "beer" # As you see, the string value is the same

string.chop!

=> "bee"

string

=> "bee" #The method call with the bang (!) is the
clue

string = string.chop #Reassigning

=> "be"

string #Guess what? Yes, string has a new value

=> "be"

In brief, to modify an object you make a call to a method with
side effects or reassign the object to the new one created after the method
call.

7

Thanks. In retrospect, this is somewhat obvious. But you're right: it
was my expectation that foo.succ was equivalent to foo+=1, rather than
simply being an expression that returned a value without modifying the
variable itself.

I appreciate all of the informative responses.

···

On Thu, Jun 07, 2007 at 01:55:23PM +0900, Ivan Salazar wrote:

This one is a very common mistake when someone is new to functional
languages specially when having some procedural language experience...
Many methods in functional languages don't have side effects (don't

--
"Oh, look: rocks!"
  -- Doctor Who, "Destiny of the Daleks"

8

I guess this means that you will be going out with a bang! :slight_smile:

(sorry. I could not resist!)

···

--
Posted via http://www.ruby-forum.com/.

9

May I have the temerity to point out that there's another subtle
misconception in this statement which I see a lot of Ruby nubies trip
up on, and that's thinking that variables are objects.

An object holds state and behavior, a variable references an object.
More than one variable can reference the same object.

Modifying an object means modifying the objects state.

Modifying a variable means changing WHICH object it is referencing.
Which is done by assignment or assignment-like things such as
providing a value to the parameter of a method or block.

I would argue that: a = a.chop! doesn't change the variable a since
it's still referring to the same object. Consider:

     a = "abc"
    # changes (sets) VARIABLE a

     b = a
     # changes (sets) VARIABLE b

     p a.object_id => -606250168
     p b.object_id => -606250168
     # note that its one OBJECT referenced by two VARIABLES

     c = a.delete('a') => "bc"
     # creates a new OBJECT leaving both VARIABLEs
     # and the OBJECT they reference unchanged.
     p a => "abc"
     p b => "abc"
     p a.object_id => -606250168
     p b.object_id => -606250168

     b.delete!('b')
     # changes the state of the OBJECT referenced by VARIABLE b
     p b => "ac"

     p b.object_id => -606250168
    # but leaves the VARIABLE b unchanged, it's still referencing the same
    # object albeit that object's state has changed.
     p a => "ac"
     p a.object_id => -606250168
    # and VARIABLE a still refers to the same (changed) OBJECT

     b = c
     # changes the VARIABLE b
     p b.object_id => -606269188
     p c.object_id => -606269188

And variable is a general term covering (local|global|instance|class)
variables as well as things like the slots in Arrays which refer to
the elements of the array.

···

On 6/7/07, Todd A. Jacobs <tjacobs-sndr-019fdb@codegnome.org> wrote:

On Thu, Jun 07, 2007 at 01:55:23PM +0900, Ivan Salazar wrote:

> This one is a very common mistake when someone is new to functional
> languages specially when having some procedural language experience...
> Many methods in functional languages don't have side effects (don't

Thanks. In retrospect, this is somewhat obvious. But you're right: it
was my expectation that foo.succ was equivalent to foo+=1, rather than
simply being an expression that returned a value without modifying the
variable itself.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

10

> > This one is a very common mistake when someone is new to functional
> > languages specially when having some procedural language experience...
> > Many methods in functional languages don't have side effects (don't

> Thanks. In retrospect, this is somewhat obvious. But you're right: it
> was my expectation that foo.succ was equivalent to foo+=1, rather than
> simply being an expression that returned a value without modifying the
> variable itself.

May I have the temerity to point out that there's another subtle
misconception in this statement which I see a lot of Ruby nubies trip
up on, and that's thinking that variables are objects.

An object holds state and behavior, a variable references an object.
More than one variable can reference the same object.

Modifying an object means modifying the objects state.

Modifying a variable means changing WHICH object it is referencing.
Which is done by assignment or assignment-like things such as
providing a value to the parameter of a method or block.

I would argue that: a = a.chop! doesn't change the variable a since
it's still referring to the same object. Consider:

     a = "abc"
    # changes (sets) VARIABLE a

     b = a
     # changes (sets) VARIABLE b

     p a.object_id => -606250168
     p b.object_id => -606250168
     # note that its one OBJECT referenced by two VARIABLES

     c = a.delete('a') => "bc"
     # creates a new OBJECT leaving both VARIABLEs
     # and the OBJECT they reference unchanged.
     p a => "abc"
     p b => "abc"
     p a.object_id => -606250168
     p b.object_id => -606250168

     b.delete!('b')
     # changes the state of the OBJECT referenced by VARIABLE b
     p b => "ac"

     p b.object_id => -606250168
    # but leaves the VARIABLE b unchanged, it's still referencing the same
    # object albeit that object's state has changed.
     p a => "ac"
     p a.object_id => -606250168
    # and VARIABLE a still refers to the same (changed) OBJECT

     b = c
     # changes the VARIABLE b
     p b.object_id => -606269188
     p c.object_id => -606269188

And variable is a general term covering (local|global|instance|class)
variables as well as things like the slots in Arrays which refer to
the elements of the array.

--
Rick DeNatale

My blog on Rubyhttp://talklikeaduck.denhaven2.com/

I agree with you, that is also a frequent misconception.

In brief, to modify an object you make a call to a method with
side effects or reassign the object to the new one created after the method
call.

The one above should read: "or reassign the variable to the new object
created".
(I don't know what happened, maybe I got confused while writing or it
was just
my good-old stupidity XD)

···

On Jun 7, 2:15 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

On 6/7/07, Todd A. Jacobs <tjacobs-sndr-019...@codegnome.org> wrote:
> On Thu, Jun 07, 2007 at 01:55:23PM +0900, Ivan Salazar wrote:

11

Just nit-picking but even with that change, it's still not quite
right, reassigning a variable doesn't modify the object it previously
referenced.

···

On 6/14/07, Ivan Salazar <ivan.salazarv@gmail.com> wrote:

On Jun 7, 2:15 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

> May I have the temerity to point out that there's another subtle
> misconception in this statement which I see a lot of Ruby nubies trip
> up on, and that's thinking that variables are objects.
>
> An object holds state and behavior, a variable references an object.
I agree with you, that is also a frequent misconception.

>In brief, to modify an object you make a call to a method with
>side effects or reassign the object to the new one created after the method
>call.

The one above should read: "or reassign the variable to the new object
created".
(I don't know what happened, maybe I got confused while writing or it
was just
my good-old stupidity XD)

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

12

Ohhh, right. I know where is the mistake... My poor english. Im still not
writing what I want to say XD.
My bad, I am very sorry. But that's what I ment to say.

···

2007/6/14, Rick DeNatale <rick.denatale@gmail.com>:

On 6/14/07, Ivan Salazar <ivan.salazarv@gmail.com> wrote:
> On Jun 7, 2:15 pm, "Rick DeNatale" <rick.denat...@gmail.com> wrote:

> > May I have the temerity to point out that there's another subtle
> > misconception in this statement which I see a lot of Ruby nubies trip
> > up on, and that's thinking that variables are objects.
> >
> > An object holds state and behavior, a variable references an object.
> I agree with you, that is also a frequent misconception.
>
> >In brief, to modify an object you make a call to a method with
> >side effects or reassign the object to the new one created after the
method
> >call.
>
> The one above should read: "or reassign the variable to the new object
> created".
> (I don't know what happened, maybe I got confused while writing or it
> was just
> my good-old stupidity XD)

Just nit-picking but even with that change, it's still not quite
right, reassigning a variable doesn't modify the object it previously
referenced.

--
Rick DeNatale

My blog on Ruby
http://talklikeaduck.denhaven2.com/

13

Nothing to be sorry about Ivan.

···

On 6/23/07, Ivan Salazar <ivan.salazarv@gmail.com> wrote:

Ohhh, right. I know where is the mistake... My poor english. Im still not
writing what I want to say XD.
My bad, I am very sorry. But that's what I ment to say.

--
Rick