Are arrays like pointers?

Sorry, kind of new to the language. Earlier in this book I’m reading,
“Learn to Program” by Chris P., he talked about how methods do not
affect variables. But in this program, it seems like the indicies of
world are affected globally.

From what I understand from looking at the code, when the method,
continent_size, finds ‘land’, it will change it to ‘counted land.’ This
“new world” with the changed ‘counted land’ then gets passed into
another continent_size, so that’s why the recursive calls will skip over
the ‘counted land.’

BUT, I would think that if 2 separate recursive calls, let’s say to
(4,5) and (6,5), which are both land, when they check (5,6), they would
BOTH count it as ‘land.’

The only way I can see this not happening is if the array, world, is
globally affected… or if there’s something about the code returning
world to itself after the recursive calls which I am not seeing.

Please help explain! Thanks!

Yes!

In Ruby, most values are not stored directly in their variables,
but rather, the variables “point to” their values.
Each variable acts as as a reference to its value.

Chris P. himself uses the term “point to” a couple of times
when he talks about variables in chapter 3 (“Variables and Assignment”).

So, variables referring to strings are “pointers” (references) just
as variables referring to arrays are.
But with arrays you tend to notice this reference behaviour more,
because arrays will get modified more often.

To illustrate, let’s apply the mutator method “<<”

Array:

a = [“a”, “b”, “c”]
b = a
a << “d”
p b # ==> [“a”, “b”, “c”, “d”] (–> Changed!)

String:

a = “abc”
b = a
a << “d”
p b # ==> “abcd” (–> Changed!)

There are a few exceptions to that principle, some values
do get stored directly instead of being “pointed to”.

That is all objects of the classes Fixnum, Symbol and Boolean
and nil.
These classes do not have any mutator methods, so you
would not notice anything different in the usage of
such immediate values, because you can’t mutate them anyway.

So, actually, Ruby programmers could live agnostically of
whether the values he/she is using are immediate or not.

…Regrettably, another quirk comes in, because immediate objects
are also Singleton objects, to which for example, you cannot send
the clone/dup methods:

42.dup # ==> TypeError: can’t dup Fixnum

Where it would actually be consistent with the rest of the language,
if 42.dup would just return…, yes, 42.

My opinion:
As Ruby already has two duplication methods, at least one of them
should be allowed to be sent to Singleton objects. This would reduce
the need for many case distinctions (for instance in deep copying).

Cheers
Sven

hi Sven S,

In Ruby, most values are not stored directly in their variables,
but rather, the variables “point to” their values.
Each variable acts as as a reference to its value.<<

I think you are wrong here, there is nowhere in Ruby values are directly
stored in variables, this includes Fixnum, Symbol and Boolean and nil.
For an example you could consider the below program and it’s output.

irb(main):001:0> a=10
=> 10
irb(main):002:0> b=a
=> 10
irb(main):003:0> a.object_id
=> 21
irb(main):004:0> b.object_id
=> 21

You could notice that object_id of both a and b are same. So a and b
both are just references not variables in the way it’s refereed in C. So
you may ask a question whether Ruby follows a pass by value or pass by
reference while we pass arguments, it’s pass by references, but another
question might sprang up from here, then why the change is not reflected
in the main function while we are doing some changes in the called
function, that’s because when we assign new value object_id
automatically changed if assigned value is not the same.

Hello Raja,

Raja gopalan wrote in post #1172991:

I think you are wrong here, there is nowhere in Ruby values are directly
stored in variables, this includes Fixnum, Symbol and Boolean and nil.
For an example you could consider the below program and it’s output.

irb(main):001:0> a=10
=> 10
irb(main):002:0> b=a
=> 10
irb(main):003:0> a.object_id
=> 21
irb(main):004:0> b.object_id
=> 21

You could notice that object_id of both a and b are same. So a and b
both are just references not variables in the way it’s refereed in C.

It seems that you are trying to conclude
that the value 10 is stored as a reference
from the fact that it returns the same object_id.

This is plainly not possible.
From mentioned behaviour (same object_id result) one cannot
distinguish the way values are stored, it could be implemented either
way and still return the same object_id.

I simply wrote about immediate values, because I have read
about them, for example:

http://www.rubyfleebie.com/understanding-fixnums/

But what matters is how the language behaves to the programmer.
So I don’t care if Fixnums are stored as immediate values or
as references, as long as they behave consistently. And that includes
returning the same object_id after an assignment, for example.
The way they are stored could even differ across Ruby implementations.

Just from a hacker’s point of view I find it interesting, that
in the MRI implementation, the integer i will be stored as the value
2 * i + 1
So 10 will be stored internally (in physical memory) as 21.

Cheers
Sven