A = Dog.new # a is not a pointer and not a reference?

Ruby
21

David A. Black wrote:

I wouldn’t say it’s a pointer. “Reference” is the universal term, as
far as I’ve heard.

What language is ruby written in? (Not jRuby or IronRuby.)

C. It sounds like you’re asking the question rhetorically, though. I’m
not sure what you mean.

C doesn’t have references. Hence, as a metaphor for Ruby, the ‘a’ in 'a

Dog.new’ is a pointer to a Dog. If we then say ‘a = Conure.new’, that
reseats ‘a’ to point at something else.

In C terms, it’s a pointer with the indirection already turned on. *a.
And…

C++ has references; ‘Dog & a = some_dog’. These are more than just
pointers
with their indirection turn on, because ‘a’ can be optimized away, and
cannot reseat. That means attempts to treat ‘a’ as a pointer (such as by
reinterpret_cast-ing its container) can lead to undefined behavior.

So Ruby methods, like Java, are pass-by-value, where the value is a copy
of
a pointer. Hence the pointed-to objects behave as pass-by-reference.

22

SpringFlowers AutumnMoon wrote:

Doesn’t a Ruby variable behave the same way in Java, PHP5, C++, and
Python?

No. Well, yes, to the extent that variables in all these languages
allow
the values of variables to vary, but that is too simple a view to be
useful beyond an introduction to programming.

As long as I view Ruby as a pointer to an object, everything clicks.

Well it it works for you fine, but for many it has problems. Languages
which have variables called pointers have values which are addresses and
some way to reference the object at the address value. In other words,
the concept of pointer carries with it the baggage that there will be
two ways to “evaluate” the variable - as an address or as an object.

Ruby variables cannot be evaluated to addresses, hence it is rather
misleading to most people to use the term pointer for a Ruby variable.
For example, in any language with pointer, p, it is reasonable to ask
in that programming language, what is the address obtained from p by
adding 8 bytes. There is no way to write this in Ruby.

So if you find it helpful and wish to say that some of the purpose of
variables in Ruby is served by some of the functions of some pointers
in languages with pointers, I doubt if any rubist would disagree. But
if you say Ruby variables are pointers in other languages, they are
likely to reply,“Rubbish”, because Ruby does not want to require the
low level bookkeeping that pointers imply.

Ian W.

23

On Sep 29, 2007, at 10:17 PM, SpringFlowers AutumnMoon wrote:

with the semantics of C or C++. Trying to impose the semantics of
other languages onto Ruby isn’t going to work. It’s best to drop such
baggage and start fresh.

hm,… but is there a problem to think of reference in Ruby as a
“pointer”? will that cause any trouble? I only see that
a.value is
not the same as C and C++ would use a->value, but in Ruby we use
the “.”
to replace the “->” and that’s it. Will there be further trouble or
discrepancy to think of Ruby reference as a pointer?

Well, your assertion that a.value is the equivalent of a->value is a
good example of getting into trouble by equating a reference to a
pointer. The expression a.value is a method call, not a value fetch.
For a.value to work, the object referred by a has have a method
called ‘value’, either an instance method or singleton method, in its
extended object table. If it does, the method is executed and some
object is returned. That’s not at all what a->value does in C.

Regards, Morton

24

Ian W. wrote:

So if you find it helpful and wish to say that some of the purpose of
variables in Ruby is served by some of the functions of some pointers
in languages with pointers, I doubt if any rubist would disagree. But
if you say Ruby variables are pointers in other languages, they are
likely to reply,“Rubbish”, because Ruby does not want to require the
low level bookkeeping that pointers imply.

I want to think of it like as a pointer to distinguish it from the C++'s
reference, which is quite different.

Maybe if C++ didn’t call that reference but called it alias, then the
word reference wouldn’t lead to some people thinking of it as C++'s
reference.

25

Morton G. wrote:

On Sep 29, 2007, at 10:17 PM, SpringFlowers AutumnMoon wrote:

with the semantics of C or C++. Trying to impose the semantics of
other languages onto Ruby isn’t going to work. It’s best to drop such
baggage and start fresh.

hm,… but is there a problem to think of reference in Ruby as a
“pointer”? will that cause any trouble? I only see that
a.value is
not the same as C and C++ would use a->value, but in Ruby we use
the “.”
to replace the “->” and that’s it. Will there be further trouble or
discrepancy to think of Ruby reference as a pointer?

Well, your assertion that a.value is the equivalent of a->value is a
good example of getting into trouble by equating a reference to a
pointer. The expression a.value is a method call, not a value fetch.
For a.value to work, the object referred by a has have a method
called ‘value’, either an instance method or singleton method, in its
extended object table. If it does, the method is executed and some
object is returned. That’s not at all what a->value does in C.

how about just a.set_value(3) vs a->set_value(3). what i mean is just
the “.” and “->” difference. using a “.” in Ruby and “->” in C or C++.
If I think of “a” as a pointer and “.” as “->”, will that get in trouble
and have any discrepancy for other things.

26

On 9/30/07, SpringFlowers AutumnMoon [email protected] wrote:

how about just a.set_value(3) vs a->set_value(3). what i mean is just
the “.” and “->” difference. using a “.” in Ruby and “->” in C or C++.
If I think of “a” as a pointer and “.” as “->”, will that get in trouble
and have any discrepancy for other things.
Yup 'cause ‘.’ is not dereferencing period (pun intended). It is
sending a message

x.a is almost equivalent to
x.send :a.

Variables in Ruby are references, period again :wink: but you cannot
dereference them.
I guess this was somehow lost in the discussion.

HTH
R.

27

SpringFlowers AutumnMoon wrote:

how about just a.set_value(3) vs a->set_value(3). what i mean is just
the “.” and “->” difference. using a “.” in Ruby and “->” in C or C++.
If I think of “a” as a pointer and “.” as “->”, will that get in trouble
and have any discrepancy for other things.

I think that this will get you into trouble only because you will
continue trying to see Ruby as working from the same OOP paradigm as
C++. There are, actually, two (common) ways to do OOP: one comes from
Simula and the other from SmallTalk.

Basically, Simula-style OOP (which is what C++ uses) treats “objects” as
structs of values and function pointers. When you say “myObject.doThis”
you are dereferencing “myObject”, which is actually a pointer to the
object struct, and then invoking the function pointed to by “doThis”.

On the other hand, SmallTalk style OOP (which is what Ruby uses) treats
objects as containers (an array or hash if you want) of values and
instantiated from a class. Classes are where the functions are held.
When you say “myObject.doThis”, the runtime engine asks the class that
“myObject” was instantiated from if it knows about a “doThis” function.
If it does, then it gives the values held by “myObject” to the “doThis”
function from the class.

The reason that concepts such as pointer and reference do translate well
between C++ and Ruby is because of this difference in paradigms. In the
Simula style, “myObject” has to know where “doThis” resides in memory,
hence why it is important to know if “myObject” is a pointer or a
reference. In the SmallTalk style, “myObject” just has to know what
class it belongs to; the runtime handles keeping track of where
functions live in memory.

This is why, as was said earlier, “myObject” in Ruby is nothing more
than a human-readable label. Without the runtime it is meaningless. To
see what this means in practice, try doing a few assignments in IRB and
after each check the object_id of the variables. You’ll see that it
changes with reassignment. This is actually the Ruby runtime applying
the labels to new objects.

Hope that helps!

Cheers,
Joshua B.

28

Joshua B. wrote:

The reason that concepts such as pointer and reference do translate well
between C++ and Ruby is because of this difference in paradigms.

Apologies. That should be “do not translate well”

29

Hi –

On Sun, 30 Sep 2007, SpringFlowers AutumnMoon wrote:

other languages onto Ruby isn’t going to work. It’s best to drop such
baggage and start fresh.

hm,… but is there a problem to think of reference in Ruby as a
“pointer”? will that cause any trouble? I only see that a.value is
not the same as C and C++ would use a->value, but in Ruby we use the “.”
to replace the “->” and that’s it. Will there be further trouble or
discrepancy to think of Ruby reference as a pointer?

Imagine if you went to a C mailing list and announced that you were
going to call pointers “references”. That’s the main issue: you’re
making up new terminology instead of using the terminology used by
creator of Ruby and by people who have been using and talking about
the language for years and years.

The dot in Ruby is the dot in Ruby. It’s not a replacement for
anything else. It’s actually pretty easy to understand; it means “send
a message to this object”. There’s no need to go looking for what it
would mean if this weren’t Ruby.

David

30

On 9/29/07, Joel VanderWerf [email protected] wrote:

A Ruby variable is nothing like a C++ variable. Never has been, never
will be.
It’s not so mysterious. If you’re coming from C/C++, you may find it
helpful to think of a ruby variable as a C void* variable. Assigning
between variables in ruby is just like C assignment between two void* vars.

No, I don’t think that’s a valid comparison because a void* still
takes up space – it’s a location – in C++. That is, I can
legitimately do:

void* a = &5;
void* b = &a;

It’s important for people to understand deeply that Ruby variables
take up no space – they’re labels. If I call something a cat and you
call that same something ‘Fluffy’, we’re still referring to the same
animal, but neither of our names for that animal can easily be
referred to by another name.

Ruby variables are “wafer-thin”. They’re, as I said, just sticky notes
that can be moved around at will. It’s the objects that take up the
space.

-austin

31

Hi –

On Sun, 30 Sep 2007, Robert D. wrote:

x.send :a.

Variables in Ruby are references, period again :wink: but you cannot
dereference them.

And I’d add that bareword identifiers are sometimes not variables,
so x.a can mean something even if x is a method call.

David

32

On 9/29/07, Morton G. [email protected] wrote:

No, he’s not. Bjarne is clearly not a mere mortal. Or from the
upper planes.
Are you implying Bjarne Stroustrup is some kind of demon? He always
struck me as a very nice person.

So are succubi :wink:

Only a being of demonic influence could have come up with the disaster
that is C++. I say this having to program in the language every day.
There’s nothing redeeming about C++.

-austin

33

On 9/29/07, Morton G. [email protected] wrote:

Try this. Without going into implementation details, of which I am
ignorant, a Ruby variable establishes an association between an
identifier and an object [*]. The association is specific to a
particular lexical scope and to a particular execution extent.
Therefore the same identifier can be associated (refer to) different
objects in different scopes and different objects at different points
of the execution. Such an association should perhaps more strictly be
called a binding rather than a reference, but ‘reference’ is often
used in informal discourse.
[…]

[*] Yes, I know this is not the whole story. I’m trying to keep
things simple.

It’s close enough to the whole story as to not matter from the Ruby
programmer’s point of view. Implementers care differently.

-austin

34

On 9/29/07, SpringFlowers AutumnMoon [email protected] wrote:

Austin Z. wrote:

A variable in Ruby isn’t like Java, PHP, C++, C, or even Pascal.
Doesn’t a Ruby variable behave the same way in Java, PHP5, C++, and
Python?

Didn’t I just say that they aren’t the same?

As long as I view Ruby as a pointer to an object, everything clicks.

But that’s exactly the WRONG way to look at it. In Pascal, Java,
C/C++, and possibly PHP5 (again, I don’t know Python’s semantics), a
variable takes up space.

In Ruby, a variable doesn’t contain anything. It doesn’t contain an
address, it doesn’t contain an object, it doesn’t contain anything. It’s
a label, a name, a sticky note attached to the object.

Forget C++, forget PHP. There are similarities, but you’re being
confused by concepts that have ZERO meaning in Ruby. So approach it from
a different direction.

I’ve seen you ask similar questions on three threads and you’re no
closer to understanding, which is why I’m telling you to forget what you
think you know.

Since Ruby variables aren’t containers (objects), they can’t be referred
to by other variables. In the code:

a = Dog.new(“phydeaux”)

a is not a pointer. Ever. You call it a pointer, and you’re going to
confuse people, especially yourself. What we say is that a is a
reference to “phydeaux”, or that it “refers to phydeaux”.

More often than not, though, we’ll be a bit smarter when we name our
variables:

class Dog
attr_accessor :name

def initialize(name)
@name = name
end

def woof
puts “Woof!”
end
end

def woof(dog)
dog.woof
end

phydeaux = Dog.new(“phydeaux”)
woof(phydeaux)

Seriously. Forget what you think you know. Because you’re not getting it
trying to relate it to anything else, and you’re just confusing the
discussion.

Ruby variables are called references. This is just a convention, but
it’s the prevailing convention. It’s not a pointer of any sort; it’s not
a C++ reference. This is because Ruby variables aren’t themselves
containers that can be referred to. It’s closest to Lisp bindings. If
that’s not clear, just remember that it has as much permanence as a
Post-It note.

-austin

35

Austin Z. wrote:

I’ve seen you ask similar questions on three threads and you’re no
closer to understanding

What makes you think that is the op’s goal?

36

On 9/30/07, 7stud – [email protected] wrote:

Austin Z. wrote:

I’ve seen you ask similar questions on three threads and you’re no
closer to understanding
What makes you think that is the op’s goal?

Because I tend to assume the best intentions in people. I see no
reason to assume otherwise.

-austin

37

7stud – wrote:

Austin Z. wrote:

I’ve seen you ask similar questions on three threads and you’re no
closer to understanding

What makes you think that is the op’s goal?

I asked similar question before although at that time I didn’t know the
word reference can mean “alias that can’t change where it points to” in
C++ and the general CS field. the word we in use in Ruby is also
reference. so trying to clarify how it relates to the rest of the
world.

38

Austin Z. wrote:

void* a = &5;
void* b = &a;

Not quite legitimately… you didn’t mean to take the address of a
literal int, did you?

Anyway, in ruby you can do:

a = [1,2,3]
b = “a”
eval b # ==> [1, 2, 3]
a = [4,5,6]
eval b # ==> [4, 5, 6]

The analogy between eval and dereferencing pointers doesn’t go very far,
but this snippet does demonstrate one thing: there is some storage,
somewhere, associated with a in this context while the program is
running. Not associated with the value of a (the array has its own
storage independent of a), but associated with the variable itself.
Without this storage there would be no way to eval the string “a”.

C/C++ doesn’t have this kind of storage: there’s no way to evaluate “a”
at run-time. The association between the string “a” and a certain memory
location has been compiled out, which is why the program uses the
numerical address of that location instead.

In ruby, the storage for a is in the binding for the scope of the
snippet above. You can think of the binding as something that has a
table whose entries have two fields: a variable name and a pointer to a
value (or an immediate value encoded in 4 bytes instead of a pointer).
That’s a different kind of storage than heap storage, where the arrays
are. Ruby makes it harder to access the storage of a binding directly
(you have to use #eval, #binding, #local_variables), but it does take up
real space and have a location in memory.

Ruby doesn’t have an operator to take the address of that location.
(Ruby doesn’t have any operators for working with addresses, except for
#object_id, and this exception is just a quirk of the implementation.)
But it is a location nonetheless. You can run out of memory by
overpopulating a binding.

39

There is a lot of confusion on this one. While I know for sure that
there are low level compiled languages that will allow the pointers to
be explicitly OR implicitly called (i.e. you are not required to use
the dereference) I do not believe that an interpreted language would
employ specific pointers.

That having been said, what is everyone basing their positions upon? Is
this more of a debate about what things are or how to word them to
others? Where did everyone look in the docs or source code to figure
this out?

40

SpringFlowers AutumnMoon wrote:

hm,… but is there a problem to think of reference in Ruby as a
“pointer”? will that cause any trouble? I only see that a.value is
not the same as C and C++ would use a->value, but in Ruby we use the “.”
to replace the “->” and that’s it. Will there be further trouble or
discrepancy to think of Ruby reference as a pointer?

Ruby variables hold the value of an object reference. Reassigning the
variable set it to a different object reference. Retrieving the value
gives you an object reference you can then pass by value to another
method or use to invoke methods on the object.

Pointers are lower-level. You can’t do pointer math with Ruby variables,
and you can never retrieve the memory address of an object, so thinking
of Ruby variables as pointers is misleading.

  • Charlie