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

ruby-talk
21

... it's best to forget the concept of a Ruby variable as a shoebox. It
doesn't *hold* anything.

In C/C++, a variable is a shoebox. This shoebox has a physical location
and dimension (the address in memory). One shoebox can hold the location
of another shoebox. That's a pointer or a reference (under the covers,
they are the same in C++).

A variable in Ruby is a sticky note (like a Post-It). You can put that
sticky note on an object, or you can put multiple sticky notes on an
object. But if you move the sticky note, you're changing the object to
which it references. Since they're labels, the sticky notes don't
contain anything -- they just name the object that they're attached to.
Since they don't contain anything, no other sticky note can point to
another sticky note.

And moving a sticky note to another object leaves any other sticky
notes where they are.

A Ruby variable is nothing like a C++ variable. Never has been, never
will be.

Excellent exposition!

(Don't think that Symbols are special, either. They're not. Ruby just
keeps a list of all sticky notes that were ever created so you can,
within a certain scope and context, see if the objects you want know
anything about those particular sticky notes. It's sort-of a master
index, that way. But it's not magic. It's how you use them that's
magic.)

There's nothing special in this regard about immediate objects like 0,
99, nil, true... either. You can stick as many post-it notes on these
as you want, even though there's only one of each.

The technical name for what these post-it notes 'hold' is an object
reference. It's an opaque value which the implementation can use to
'finger' a particular object. This shouldn't be confused with the
object id which you might think of as a unique serial number magically
stamped onto each object.

And as I pointed out on another thread today, if you think of the
parameter passing mechanism as neither call by value, or call by
reference, but as call by object reference it might clarify things.

> [*] Betrand Meyer of Eiffel fame has often made fun of C++'s reference
> semantics. He has claimed they are beyond the understanding of mere
> mortals. He is joking, of course.

No, he's not. Bjarne is clearly not a mere mortal. Or from the upper
planes.

At some early OOPSLA (late 1980s/early 1990s) Apple was showing off
their new C++ compiler for the Macintosh Programmers Workshop.

Stroustrup was strolling through the exhibits and wandered into the
Apple booth. One of the Apple guys grabbed him and proudly showed him
that Apple now had a C+ compiler.

Bjarne stood at the computer and typed in a little "Hello world" C++ program.

After about 3 or four tries HE finally got all of the syntax errors
out of his trial program, and this wasn't due to bugs in Apple's
compiler.

···

On 9/29/07, Austin Ziegler <halostatue@gmail.com> wrote:

> On Sep 29, 2007, at 1:16 PM, SpringFlowers AutumnMoon wrote:
On 9/29/07, Morton Goldberg <m_goldberg@ameritech.net> wrote:

--
Rick DeNatale

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

22

Yep.
You're not guaranteed (AFAIK) any direct memory access in Ruby, nor should you be concerned about it. It is Ruby. The goal is to allow you to focus on programming and making things happen. If you want access and control at a lower level, you'll need to use a language like C or C++ or perhaps Objective-C (don't know if Obj-C 2.0, coming in a month or so, will allow such low level access)
In Ruby just think about identifiers as references to objects. The only case that requires a little time to get a hang of is Ruby's Symbol class. They could be described as constant references (for the life of the program) and should be used carefully like globals. You don't want too many of them, but with any modern system you should have reasonable amount of headroom, unless you're dealing with a huge data set.
With Ruby, like SmallTalk, you're pretty much always dealing with objects and nothing much lower-level like pointers or primitive types.

···

On Sep 29, 2007, at 1:46 PM, Gary Wright wrote:

On Sep 29, 2007, at 2:12 PM, SpringFlowers AutumnMoon wrote:

Morton Goldberg wrote:

On Sep 29, 2007, at 1:16 PM, SpringFlowers AutumnMoon wrote:

I think it best to think of a Ruby variable as holding a reference to
an object. Ruby's reference semantics are different from C++'s, but
IMO more mainstream. C++'s reference semantics are peculiar, to say
the least, and perhaps even unique [*]. Ruby's variable semantics are
simple and clean when compared to C++, so I recommend forgetting
about making such comparisons.

hm... so you mean best to think of a Ruby variable as holding a pointer
to an object? I hope either

1) we use the word "reference" to mean a pointer
2) or, we just use the word pointer instead,

I think that 'pointer', for most programmers, means an explicit memory
address. Ruby references should not be understood as explicit memory
addresses but instead as opaque values that are processed by the
underlying Ruby implementation as necessary to locate or 'reference'
the associated object.

At the level of a Ruby programmer I think it is best to discard the
idea of 'pointer' entirely and think entirely about references to
objects. At the level of a Ruby language implementor it becomes
necessary at some point to discuss how a Ruby reference can be
converted to a pointer to a chunk of memory, but that is an implementation
detail that shouldn't concern a Ruby application programmer.

Gary Wright

23

SpringFlowers AutumnMoon wrote:

$a = new Dog("lulu"); # a is a reference to "lulu" object
$c = $a; # c is a reference to "lulu" object
$b = &$a; # b is a reference to reference ?
$b = new Dog("woofy");

actually, i think it would be better to name them differently:

$a = new Dog("lulu"); # a is a reference to "lulu" object
$c = $a; # c is a reference to "lulu" object
$b = &$a; # b is an alias to reference ?
$b = new Dog("woofy");

or

$a = new Dog("lulu"); # a is a pointer to "lulu" object
$c = $a; # c is a pointer to "lulu" object
$b = &$a; # b is a reference to pointer ?
$b = new Dog("woofy");

as they are different things. before, i tend to think of alias as just
a pointer, but people in C++ and Java told me i can't, because pointer
can point any where, but an alias cannot. we cannot change where an
alias points to, and if we change anything, it will always be changing
the thing where it points to.

Come to think about it, a pointer is very clear cut... an alias is very
clear cut. but when it is "reference", then you have to think whether
it is the pointer behavior or the alias behavior.

···

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

24

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.

···

--
  Phlip

25

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 Whitlock

···

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

26

I don't know. I'm not sure what a "Dragomir" is. If it's a name, its
definitely not the guy. Dr. Meyer is Bertrand Meyer, an influential
French computer science type now living in Zurich if memory serves. If
"Dragomir" is a funky way to say "Doctor", then it very well could be.
Dr. Meyer has spent a lot of time in magazine articles, at least, going
over and over the problems with the C++ school of language design.

···

On Sun, 2007-30-09 at 21:02 +0900, Robert Dober wrote:

        I spoke with Dr. Meyer during his trip to China last year.
        One of the things we touched upon (naturally) was programming
        language design. He is not joking when he talks about C++'s
        reference semantics. Not in the slightest. Don't mistake his
        general good cheer and good nature for not vociferously hating
        that language. :wink:

Just out of curiosity, is this the Dragomir Meyer who wrote "50
pitfalls in C++"? (The only book I ever read about C++, but it was
worth it's money because it made me stay away!)

--
Michael T. Richter <ttmrichter@gmail.com> (GoogleTalk:
ttmrichter@gmail.com)
I can see computers everywhere - except in the productivity statistics!
(Robert Solow)

27

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

···

On 9/29/07, Joel VanderWerf <vjoel@path.berkeley.edu> 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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

28

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

···

On 9/29/07, Morton Goldberg <m_goldberg@ameritech.net> 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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

29

Austin Ziegler 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

···

On 9/29/07, SpringFlowers AutumnMoon <summercoolness@gmail.com> wrote:
--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca

30

But these things happen sometimes, was there not a famous guy in the
Perl community - called Leo Tötsch IIRC - who wrote tons of patches
for the perl interpreter hardly knowing Perl?

BTW, Matz could you please post a correct Hello World program in Ruby,
you do not have to get it right the first time, second time still
beats Bjarne ;).

Robert

···

On 10/2/07, Rick DeNatale <rick.denatale@gmail.com> wrote:

Stroustrup was strolling through the exhibits and wandered into the
Apple booth. One of the Apple guys grabbed him and proudly showed him
that Apple now had a C+ compiler.

Bjarne stood at the computer and typed in a little "Hello world" C++ program.

After about 3 or four tries HE finally got all of the syntax errors
out of his trial program, and this wasn't due to bugs in Apple's
compiler.

--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/

31

No, you do not. Ruby has it own semantics, which do not correspond 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.

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.

This the way I think of it. It's an old Lisp programmer's point of view, but I think it's a reasonably good model for Ruby. It has worked well for me -- kept me out of trouble. And if I'm guilty of wrongly imposing Lisp semantics on Ruby, I'm sure I'll be corrected :slight_smile:

Regards, Morton

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

···

On Sep 29, 2007, at 8:18 PM, SpringFlowers AutumnMoon wrote:

Come to think about it, a pointer is very clear cut... an alias is very
clear cut. but when it is "reference", then you have to think whether
it is the pointer behavior or the alias behavior.

32

Ian Whitlock 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.

···

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

33

I spoke with Dr. Meyer during his trip to China last year. One of the
things we touched upon (naturally) was programming language design. He is
not joking when he talks about C++'s reference semantics. Not in the
slightest. Don't mistake his general good cheer and good nature for not
vociferously hating that language. [image: ;)]

Just out of curiosity, is this the Dragomir Meyer who wrote "50 pitfalls
in C++"? (The only book I ever read about C++, but it was worth it's money
because it made me stay away!)

I don't know. I'm not sure what a "Dragomir" is. If it's a name, its
definitely not the guy. Dr. Meyer is Bertrand Meyer,

yup I think that's him, please note that if his parents had called him
Dragomir they would have saved him years of studies, but seriously he seems
to be one on the brilliant side.

an influential French computer science type

personne n'est parfait

now living in Zurich if memory serves. If "Dragomir" is a funky way to say

"Doctor", then it very well could be.

This is indeed a very old joke, now you know it too :wink:

Robert

···

On 9/30/07, Michael T. Richter <ttmrichter@gmail.com> wrote:

On Sun, 2007-30-09 at 21:02 +0900, Robert Dober wrote:

34

Austin Ziegler 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?

···

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

35

Sure there is. I am married because of C++. Before C++ I kinda-sorta
enjoyed my job. After the C++ fiasco hit the industry in the '90s, I
increasingly despised it. Finally I tossed it all away and got a job
that didn't involve 12+ hours per day, 7 days per week of hating my work
and my life. This allowed me the social life I needed to, you know,
actually meet people and finally wind up married. :smiley:

Had I been programming with a language that didn't suck over that
period, I'd still be working 12+ hours per day, 7 days per week. I just
wouldn't have hated my life in the process. :wink:

···

On Sun, 2007-30-09 at 22:45 +0900, Austin Ziegler wrote:

There's *nothing* redeeming about C++.

--
Michael T. Richter <ttmrichter@gmail.com> (GoogleTalk:
ttmrichter@gmail.com)
Theory is knowledge that doesn't work. Practice is when everything works
and you don't know why. (Hermann Hesse)

36

Austin Ziegler 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;

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.

···

On 9/29/07, Joel VanderWerf <vjoel@path.berkeley.edu> wrote:

--
        vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407

37

Austin Ziegler wrote:

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.

Ruby variables take up just as much space, they just do it in the call stack rather than on the heap. They don't move around, you can't define new ones in a given scope after it's been parsed and activated (except for a few oddities in eval), and they have specific locations in memory for the duration of a given activation. Each variable name represents a slot in the local scope of the method activation. Some slots are named, some aren't; flip-flops, for example, get anonymous slots.

Ruby variables hold the value of an object reference. If you re-assign them, you are setting them to a different object reference. If you retrieve them, you're getting an object reference which you can then pass by value or use to invoke methods.

- Charlie

38

Austin Ziegler wrote:

Austin Ziegler 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.

In exactly the same way as Java variables don't take up space...except that they do. The same logic applies in both cases, and the analogy breaks down in the same way.

A Java local variable does not take up space any differently than a Ruby local variable takes space; it's a slot in a stack frame. I'll stick by named slots being the most straightforward way to refer to Ruby (or Java) local variables.

- Charlie

···

On 9/29/07, SpringFlowers AutumnMoon <summercoolness@gmail.com> wrote:

39

Morton Goldberg wrote:

···

On Sep 29, 2007, at 8:18 PM, SpringFlowers AutumnMoon wrote:

Come to think about it, a pointer is very clear cut... an alias is
very
clear cut. but when it is "reference", then you have to think whether
it is the pointer behavior or the alias behavior.

No, you do not. Ruby has it own semantics, which do not correspond
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?

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

40

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

-austin

···

On 9/29/07, Morton Goldberg <m_goldberg@ameritech.net> 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.

--
Austin Ziegler * halostatue@gmail.com * http://www.halostatue.ca/
               * austin@halostatue.ca * You are in a maze of twisty little passages, all alike. // halo • statue
               * austin@zieglers.ca