Reference vs. Reference

ruby-talk
1

I feel there is a subtle point that needs clarification.
Unfortunately the term "reference" does not have an unambiguous
meaning in our field. I know at least these meanings

1. R. is a general term for any programming language construct that
allows to reference a value. This does not sound very involved but
it's actually as simple (or: as general) as that. :slight_smile: Unfortunately
this includes things like C pointers, Pascal pointers, C++ references,
Perl references, Ruby references (Matz, is this the proper term?) etc.

2. C++ R. type is a special beast which has some additional properties
compared to 1. This does not only allow to reference a value but in
fact you can say that it references a reference[1]. Or you can say
that a C++ reference is an alias for a variable. Hence it allows to
manipulate a variable in a calling scope.

See also http://en.wikipedia.org/wiki/Reference#Computer_science

Ruby's evaluation strategy is actually "call by reference" although
the description at
http://en.wikipedia.org/wiki/Call_by_reference#Call_by_reference does
not cover Ruby properly - unless you interpret "temporary object" as
"copy of a reference" because this is how it works.

Note: I do not cover special cases like Fixnums here because from the
Ruby programmer's perspective there is no difference in behavior -
just in speed and memory.

Kind regards

robert

2

I feel there is a subtle point that needs clarification.
Unfortunately the term "reference" does not have an unambiguous
meaning in our field. I know at least these meanings

1. R. is a general term for any programming language construct that
allows to reference a value. This does not sound very involved but
it's actually as simple (or: as general) as that. :slight_smile: Unfortunately
this includes things like C pointers, Pascal pointers, C++ references,
Perl references, Ruby references (Matz, is this the proper term?) etc.

2. C++ R. type is a special beast which has some additional properties
compared to 1. This does not only allow to reference a value but in
fact you can say that it references a reference[1]. Or you can say
that a C++ reference is an alias for a variable. Hence it allows to
manipulate a variable in a calling scope.

See also Reference - Wikipedia

Ruby's evaluation strategy is actually "call by reference"

Sorry Robert but I challange that statement, "call by value" by all means
I also think that I am not the only one to do so.
If it were call by reference we could change parameters of immediate
values, which we can not:
a = 42
def change b
   b = 22
end
change a
p a # --> 42

although
the description at
Evaluation strategy - Wikipedia does
not cover Ruby properly - unless you interpret "temporary object" as
"copy of a reference" because this is how it works.

Maybe call by copy is the exact term; what you think?

Note: I do not cover special cases like Fixnums here because from the
Ruby programmer's perspective there is no difference in behavior -
just in speed and memory.

Why would Fixnums (e.g. intermediate values) be a special case for
call semantics?

Kind regards

robert

Likewise squared :wink:

···

On 10/1/07, Robert Klemme <shortcutter@googlemail.com> wrote:

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

3

2. C++ R. type is a special beast which has some additional properties
compared to 1. This does not only allow to reference a value but in
fact you can say that it references a reference[1]. Or you can say
that a C++ reference is an alias for a variable. Hence it allows to
manipulate a variable in a calling scope.

A reference to another reference is explicitly disallowed in C++;
attempt to do this usually result in a reference to the original object.
The implication of this is that you cannot change a reference once it is
created; you can only change the object to which it refers.

As you point out, variable alias is an apt description of a C++
reference.

References in Ruby are IMO very similar to references in C++, with the
exception of assignment semantics. Assignment on a reference in C++
calls the referred object's assignment operator, while assignment on a
reference in Ruby reassigns the reference.

Ruby's evaluation strategy is actually "call by reference" although
the description at
Evaluation strategy - Wikipedia does
not cover Ruby properly - unless you interpret "temporary object" as
"copy of a reference" because this is how it works.

This description sounds very C++-centric to me. In particular, I've
never heard Lvalue used as part of the definition of call-by-reference
(the discussion page seems to back me up on this a little). I think
foldoc's definition is better:

  call-by-reference from FOLDOC

  call-by-reference

  <programming> An argument passing convention where the address of an
  argument variable is passed to a function or procedure, as opposed to
  passing the value of the argument expression. Execution of the
  function or procedure may have side-effects on the actual argument as
  seen by the caller. The C language's "&" (address of) and "*"
  (dereference) operators allow the programmer to code explicit
  call-by-reference. Other languages provide special syntax to declare
  reference arguments (e.g. ALGOL 60).

Under strict interpretation of this definition I think Ruby is not
call-by-reference, since the address of a variable is never passed, but
rather the object to which the variable refers. Strictly speaking, Ruby
is call by value (of the variable), but since this isn't very
descriptive of how Ruby actually works, call by object reference sounds
better to me.

I think the muddiness comes from the terms not being descriptive enough
in their naming; they don't describe in their names what entity is being
passed by value or reference (be it object, variable, or otherwise).
The call by object reference suggestion addresses this issue perfectly.

Also note that the C2 wiki gives a third definition of
call-by-reference:

http://c2.com/cgi/wiki?CallByReference

Paul

···

On Tue, Oct 02, 2007 at 12:29:37AM +0900, Robert Klemme wrote:

4

I feel there is a subtle point that needs clarification.
Unfortunately the term "reference" does not have an unambiguous
meaning in our field. I know at least these meanings

1. R. is a general term for any programming language construct that
allows to reference a value. This does not sound very involved but
it's actually as simple (or: as general) as that. :slight_smile: Unfortunately
this includes things like C pointers, Pascal pointers, C++ references,
Perl references, Ruby references (Matz, is this the proper term?) etc.

2. C++ R. type is a special beast which has some additional properties
compared to 1. This does not only allow to reference a value but in
fact you can say that it references a reference[1]. Or you can say
that a C++ reference is an alias for a variable. Hence it allows to
manipulate a variable in a calling scope.

See also Reference - Wikipedia

Ruby's evaluation strategy is actually "call by reference"

Sorry Robert but I challange that statement,

It's a free country... :slight_smile:

"call by value" by all means
I also think that I am not the only one to do so.

You are not insinuating that the truth value of your statement somehow depends on the higher number of supporters, do you? :slight_smile:

If it were call by reference we could change parameters of immediate
values, which we can not:
a = 42
def change b
   b = 22
end
change a
p a # --> 42

Well, I believe the error is in reading "reference" in "call by reference" as "C++ reference" (see the initial section of my posting). In C++ land "reference" has a special meaning that is not identical with the general term "reference", which is used in the equally general term "call by reference".

Counter challenge: If Ruby was using "call by value" this bit would print "" and not "X", because t() would see a /copy of the string/:

$ ruby -e 'def t(x)x<<"X"end;s="";t s;p s'
"X"

although
the description at
Evaluation strategy - Wikipedia does
not cover Ruby properly - unless you interpret "temporary object" as
"copy of a reference" because this is how it works.

Maybe call by copy is the exact term; what you think?

I have never heard this term before; I would guess it's not a standard CS term. One could argue that Ruby uses something like "call by copy of reference" because that's basically what happens. But I haven't seen this term either; I don't think it is standard. So I'd say it's "call by reference" because that describes best what happens, especially that callers see manipulations of objects. And the fact that Ruby does not have the aliasing effects that C++ references exhibit does not disqualify the term "call by reference" for Ruby.

Behavior wise it's the same as passing a pointer to a C function. You can change the pointer in the function without affecting the pointer in the caller. Yet both refer on function invocation to the same value.

Note: I do not cover special cases like Fixnums here because from the
Ruby programmer's perspective there is no difference in behavior -
just in speed and memory.

Why would Fixnums (e.g. intermediate values) be a special case for
call semantics?

Because technically (i.e. under the hoods) the reference *is* the value. But from a language behavior point of view (i.e. ignoring the implementation) there is no observable difference. I always find it easier to grasp when this special case is not pointed out initially. It's a mere implementation detail of Ruby but does not affect how the language works.

Kind regards

robert

Likewise squared :wink:

Raised to the power of three. :slight_smile:

  robert

···

On 01.10.2007 22:07, Robert Dober wrote:

On 10/1/07, Robert Klemme <shortcutter@googlemail.com> wrote:

5

2. C++ R. type is a special beast which has some additional properties
compared to 1. This does not only allow to reference a value but in
fact you can say that it references a reference[1]. Or you can say
that a C++ reference is an alias for a variable. Hence it allows to
manipulate a variable in a calling scope.

A reference to another reference is explicitly disallowed in C++;
attempt to do this usually result in a reference to the original object.
The implication of this is that you cannot change a reference once it is
created; you can only change the object to which it refers.

As you point out, variable alias is an apt description of a C++
reference.

References in Ruby are IMO very similar to references in C++, with the
exception of assignment semantics. Assignment on a reference in C++
calls the referred object's assignment operator, while assignment on a
reference in Ruby reassigns the reference.

Ruby's evaluation strategy is actually "call by reference" although
the description at
Evaluation strategy - Wikipedia does
not cover Ruby properly - unless you interpret "temporary object" as
"copy of a reference" because this is how it works.

This description sounds very C++-centric to me. In particular, I've
never heard Lvalue used as part of the definition of call-by-reference
(the discussion page seems to back me up on this a little). I think
foldoc's definition is better:

  call-by-reference from FOLDOC

  call-by-reference

  <programming> An argument passing convention where the address of an
  argument variable is passed to a function or procedure, as opposed to
  passing the value of the argument expression. Execution of the
  function or procedure may have side-effects on the actual argument as
  seen by the caller. The C language's "&" (address of) and "*"
  (dereference) operators allow the programmer to code explicit
  call-by-reference. Other languages provide special syntax to declare
  reference arguments (e.g. ALGOL 60).

Under strict interpretation of this definition I think Ruby is not
call-by-reference, since the address of a variable is never passed, but
rather the object to which the variable refers.

Not the object is passed but the address / handle or however you want to name it. If it were the object we'd have call by value IMHO (objects are values in Ruby).

Strictly speaking, Ruby
is call by value (of the variable), but since this isn't very
descriptive of how Ruby actually works, call by object reference sounds
better to me.

Yep, I've settled with call by object reference. However, I still believe that call by reference is closer than call by value because the latter would imply that copies of objects are passed and so modifications of objects cannot have side effects on the caller. This is a dangerous assumption. :slight_smile:

I think the muddiness comes from the terms not being descriptive enough
in their naming; they don't describe in their names what entity is being
passed by value or reference (be it object, variable, or otherwise).

Good point. Side note: I find it extremely interesting how much debate we can have about terms in a subject as formalized as computer science.

The call by object reference suggestion addresses this issue perfectly.

Right.

Also note that the C2 wiki gives a third definition of
call-by-reference:

http://c2.com/cgi/wiki?CallByReference

Actually I believe this is not a third definition of call by reference but the same we had before (wikipedia). I'd disregard the comment in italics because IMHO that makes the mistake to use C++ reference semantics here. IMHO the crucial bit about CBR is the aliasing effect, i.e. modifications of the value are visible to the caller.

Kind regards

  robert

···

On 04.10.2007 19:45, Paul Brannan wrote:

On Tue, Oct 02, 2007 at 12:29:37AM +0900, Robert Klemme wrote:

6

> Ruby's evaluation strategy is actually "call by reference" although
> the description at
> Evaluation strategy - Wikipedia does
> not cover Ruby properly - unless you interpret "temporary object" as
> "copy of a reference" because this is how it works.

This description sounds very C++-centric to me. In particular, I've
never heard Lvalue used as part of the definition of call-by-reference
(the discussion page seems to back me up on this a little). I think
foldoc's definition is better:

  call-by-reference from FOLDOC

...

Also note that the C2 wiki gives a third definition of
call-by-reference:

http://c2.com/cgi/wiki?CallByReference

The common theme with all of the above links is that the caller gives
some kind of reference to an lvalue (i.e. variable) either implicitly
or explicitly (i.e. C &) and the function may dereference implicitly
or explicitly (i.e. C *) the corresponding argument to get or set the
lvalue.

There are a whole slew of languages that pass arguments like ruby.
Most seem to call it call-by-value where the value is an object
handle/pointer/reference. Python guys call it
call-by-object-reference. I like what is said on c2.com:

"Perhaps it's C/C++ background sneaking through... in a language with
value semantics such as C/C++, pointers are how you do
CallByReference. In languages with reference semantics (most OO
languages, Java for objects but not for intrinsics), one could argue
that the "handle" to the object is the value (and passing the handle
is CallByValue); performing a second indirection and passing a
reference to the handle (in C/C++ terminology, a Foo **) is how you do
CallByReference. In which case, many OO languages do not allow
CallByReference; using this definition (in Java) all calls are by
value."

Like Java, Ruby does have the equivalent of "intrinsics". They are
the immediates (Fixnum, TrueClass, FalseClass, NilClass, and Symbol)
which when used behave like the more conventional call-by-value.

If you really wanted to get the semantics of call-by-reference in
ruby, you'd have to do something like the following.

def foo(get_bar, set_bar)
    get_bar # get the value of the bar reference : 123
    set_bar[345] # set the value of the bar reference
    get_bar # 345
end

bar = 123
foo(lambda {bar}, lambda {|v| bar=v})

Of course you could combine the getter/setter into one lambda (with an
optional setting value) and/or wrap this into an object to make it
look prettier.

Eric

···

On 10/4/07, Paul Brannan <pbrannan@atdesk.com> wrote:

7

I agree with Robert Dober. What ruby does is not call-by-reference.
Every other place I've seen this phrase used it means that when you
pass an lvalue to the function and the function modifies the
corresponding argument, it modifies that lvalue. The "reference" in
call-by-reference is a reference to an lvalue, not an object. C++
isn't the only language that has this concept.

In C, you can emulate this concept easily by passing the address of an
lvalue and the function dereferencing that pointer to modify the
lvalue. There is no easy built-in way to do this in Ruby. The
solution is typically to return the new value and have the caller
explicitly assign the lvalue.

I'm not saying that the functionality that Ruby has is a major issue
(although there have been occasions where I've wanted a pointer
concept), but saying that it does call-by-reference is just not true.

The calling mechanism in Ruby seems closest to passing pointers to
values in C, where all variables also contain pointers to values. I
think of all ruby variables as object pointers and it makes sense to
me. If I needed to put a name to calling mechanism (which I don't), I
guess I'd say call-by-pointer. The pointer doesn't necessarily have
to be a memory address though. Or you might say that ruby's variables
are all object pointers and ruby does call by value.

Eric

···

On 10/1/07, Robert Klemme <shortcutter@googlemail.com> wrote:

On 01.10.2007 22:07, Robert Dober wrote:
>> although
>> the description at
>> Evaluation strategy - Wikipedia does
>> not cover Ruby properly - unless you interpret "temporary object" as
>> "copy of a reference" because this is how it works.
> Maybe call by copy is the exact term; what you think?

I have never heard this term before; I would guess it's not a standard
CS term. One could argue that Ruby uses something like "call by copy of
reference" because that's basically what happens. But I haven't seen
this term either; I don't think it is standard. So I'd say it's "call
by reference" because that describes best what happens, especially that
callers see manipulations of objects. And the fact that Ruby does not
have the aliasing effects that C++ references exhibit does not
disqualify the term "call by reference" for Ruby.

Behavior wise it's the same as passing a pointer to a C function. You
can change the pointer in the function without affecting the pointer in
the caller. Yet both refer on function invocation to the same value.

8

I'm catching up after being away for a few days, and this seems to
have been a hot topic lately.

I've seen the term call by object reference used many times in the
past to distinguish what happens in languages like Ruby and Smalltalk
from the usual meaning of call by reference.

The difference is that call by reference implies giving the called
routine read/write access to the variable which holds a reference to
some data. And call by object reference gives the called method read
access to a reference to an object. The called routine can NOT change
the reference, it can only invoke methods on the referenced object.

Note that although Ruby does allow assignment to a parameter
'variable' this is only moving a 'sticky note' to use Austin Z's nice
analogy.

···

--
Rick DeNatale

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

9

After reading this interesting thread, I think we might have a chance
at coining a new term here. How about:

Call by copied reference? Or call by temporary reference? I don't
see anything particularly "objecty" about this distinction, per se.
I think it is a truly different passing convention that has convenient
merits distinct from the coarse approximations mentioned earlier.
Best regards,

-r.

10

There are a whole slew of languages that pass arguments like ruby.
Most seem to call it call-by-value where the value is an object
handle/pointer/reference. Python guys call it
call-by-object-reference.

Not just python guys. The term predates python by quite a bit. I'm
pretty sure it was used in the Smaltalk literature, and a recent
google search showed it in papers on Emerald, and distributed OO
language from the 1980s.

Like Java, Ruby does have the equivalent of "intrinsics". They are
the immediates (Fixnum, TrueClass, FalseClass, NilClass, and Symbol)
which when used behave like the more conventional call-by-value.

Part of the problem with this whole discussion is that it's crossing
meta-levels. Immediates/intrinsics exist in the implementation, below
the language level. To the Java/Smalltalk/Ruby programmer the
encoding of object references is invisible. Object references are
object references.

The only relevant difference between say a Fixnum and an Array is that
all instances of Fixnum are immutable. Since there are no methods on 1
which can mutate it to 2 or any other object a method which gets it as
an argument can't change it.

If you really wanted to get the semantics of call-by-reference in
ruby, you'd have to do something like the following.

def foo(get_bar, set_bar)
    get_bar # get the value of the bar reference : 123
    set_bar[345] # set the value of the bar reference
    get_bar # 345
end

bar = 123
foo(lambda {bar}, lambda {|v| bar=v})

Of course you could combine the getter/setter into one lambda (with an
optional setting value) and/or wrap this into an object to make it
look prettier.

This is more like call-by-name with the lambda(s) acting as a thunk.

···

On 10/5/07, Eric Mahurin <eric.mahurin@gmail.com> wrote:

--
Rick DeNatale

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

11

>Under strict interpretation of this definition I think Ruby is not
>call-by-reference, since the address of a variable is never passed, but
>rather the object to which the variable refers.

Not the object is passed but the address / handle or however you want to
name it. If it were the object we'd have call by value IMHO (objects
are values in Ruby).

Perhaps I wasn't clear. I meant:

>Under strict interpretation of this definition I think Ruby is not
>call-by-reference, since the address of a (variable is never passed, but
>rather the object)...

Sigh. I wish English had explicitly specified order of evaluation like
Ruby does. :slight_smile:

Paul

···

On Fri, Oct 05, 2007 at 04:50:04AM +0900, Robert Klemme wrote:

12

Semantically, nil, false, etc. are simply object references (to
singleton objects). Whether they are represented as "intrinsics" behind
the scenes is an implementation detail which is not shared by all Ruby
implementations.

-mental

···

On Fri, 2007-10-05 at 13:10 +0900, Eric Mahurin wrote:

Like Java, Ruby does have the equivalent of "intrinsics". They are
the immediates (Fixnum, TrueClass, FalseClass, NilClass, and Symbol)
which when used behave like the more conventional call-by-value.

13

That's pretty much how I feel things are, if "call by object
reference" is used in the Smalltalk community I see no obvious reason
why not to steal it ;). Ruby and Smalltalk do share the parameter
passing semantics after all.

A side remark to Robert's witty remark about the "truth value and
number of supporters". This was really funny and a good defense, but
on the serious side, I honor the opinions of most of the lists
'regulars', even if I do not show it well all the time - which is bad
style from my part :(. (Comment ça va Xavier? :wink:

Cheers
Robert

···

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

I'm catching up after being away for a few days, and this seems to
have been a hot topic lately.

I've seen the term call by object reference used many times in the
past to distinguish what happens in languages like Ruby and Smalltalk
from the usual meaning of call by reference.

The difference is that call by reference implies giving the called
routine read/write access to the variable which holds a reference to
some data. And call by object reference gives the called method read
access to a reference to an object. The called routine can NOT change
the reference, it can only invoke methods on the referenced object.

Note that although Ruby does allow assignment to a parameter
'variable' this is only moving a 'sticky note' to use Austin Z's nice
analogy.

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

14

Au contraire, it's very objecty.

The key is that the called code can ONLY interact with the actual
parameter as an object, not as a pointer, and not as a directly
manipulable value. Any side effects involve calling methods on the
object.

···

On 10/4/07, Rudi Cilibrasi <cilibrar@gmail.com> wrote:

After reading this interesting thread, I think we might have a chance
at coining a new term here. How about:

Call by copied reference? Or call by temporary reference? I don't
see anything particularly "objecty" about this distinction, per se.
I think it is a truly different passing convention that has convenient
merits distinct from the coarse approximations mentioned earlier.
Best regards,

--
Rick DeNatale

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

15

<snip>

Part of the problem with this whole discussion is that it's crossing
meta-levels. Immediates/intrinsics exist in the implementation, below
the language level. To the Java/Smalltalk/Ruby programmer the
encoding of object references is invisible. Object references are
object references.

Not for Java - we can not accept Java in the same league as Smalltalk
and Ruby can we ? ;).
While in Smalltalk and Ruby I can and shall handle a Fixnum as an
imutable object
in Java I cannot.
IIRC this fact is somehow hidden in version 1.5+ by some mechanism of
Autoboxing but I am not sure about that.
Robert

···

On 10/5/07, Rick DeNatale <rick.denatale@gmail.com> wrote:
--
what do I think about Ruby?
http://ruby-smalltalk.blogspot.com/

16

For the getter you are correct, it is indeed deferred evaluation like
call-by-name. But, in the above we also have the ability to assign to
an lvalue, which call-by-name doesn't (normally) have. If the getter
and setter respectively evaluate and assign the same lvalue
expression, the semantics are the same as call-by-reference. How this
is done is just an implementation detail. Here would be another way
with just a single lambda:

def foo(bar)
    bar # get the value of the bar reference : 123
    bar[345] # set the value of the bar reference
    bar # 345
end

bar = 123
foo(lambda { |*v| (v.empty?) ? bar : (bar = v[0]) } )

Something like this is the closest that ruby has to call-by-reference.

Eric

···

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

> If you really wanted to get the semantics of call-by-reference in
> ruby, you'd have to do something like the following.
>
> def foo(get_bar, set_bar)
> get_bar # get the value of the bar reference : 123
> set_bar[345] # set the value of the bar reference
> get_bar # 345
> end
>
> bar = 123
> foo(lambda {bar}, lambda {|v| bar=v})
>
> Of course you could combine the getter/setter into one lambda (with an
> optional setting value) and/or wrap this into an object to make it
> look prettier.

This is more like call-by-name with the lambda(s) acting as a thunk.

17

I'm sorry, but now I'm confused. Either I originally understood what
you meant or I'm missing something in the new version. Maybe it's
time to leave the office and have a nap...

Kind regards

robert

···

2007/10/5, Paul Brannan <pbrannan@atdesk.com>:

On Fri, Oct 05, 2007 at 04:50:04AM +0900, Robert Klemme wrote:
> >Under strict interpretation of this definition I think Ruby is not
> >call-by-reference, since the address of a variable is never passed, but
> >rather the object to which the variable refers.
>
> Not the object is passed but the address / handle or however you want to
> name it. If it were the object we'd have call by value IMHO (objects
> are values in Ruby).

Perhaps I wasn't clear. I meant:

> >Under strict interpretation of this definition I think Ruby is not
> >call-by-reference, since the address of a (variable is never passed, but
> >rather the object)...

18

Hi,

In PHP 4 and 5 you have references which work similar like C++ references. E.g. you can make a variable reference another variable after which if you change the value of one of those variables the other variable's value will also be "updated". An example:

$x = 1;
$y = &$x; // y references x
$x = 2;
echo $y; // 2
$y = 3;
echo $x; // 3

In PHP 4 you always had to pass objects by reference if you didn't want to end up with a copy of your object.

$x = new Object();
$x->value = 1;
$y = $x; // copy
echo $y->value; // 1
$y->value = 2;
echo $x->value; // 1
$x->value = 3;
echo $y->value; // 2
$y = &$x; // reference
echo $y->value; // 3
$y->value = 4;
echo $x->value; // 4;
$x->value = 5;
echo $y->value; // 5

However, in PHP 5 they introduced a concept similar to the "references" we know in Ruby. But because they already used the term "reference" they had to come up with a different name, so they call them object handles. If you assign an object to a variable you are assigning an object handle to the variable. If you assign the value of the first variable to another variable you are assigning it the same object handle. So both variables "reference" the same object. But if you now assign another object to the first (or second) variable, only that variable's content changes. E.g.

$x = new stdClass();
$y = $x; // assign object handle
$x->value = 2;
echo $y->value; // 2
$y->value = 3;
echo $x->value; // 3
$x = new stdClass(); // assign different object handle
$x->value = 1;
echo $y->value; // 3

So maybe we should call them handles instead of references to clarify the difference?

Regards,

Peter

19

> I'm catching up after being away for a few days, and this seems to
> have been a hot topic lately.
>
> I've seen the term call by object reference used many times in the
> past to distinguish what happens in languages like Ruby and Smalltalk
> from the usual meaning of call by reference.
>
> The difference is that call by reference implies giving the called
> routine read/write access to the variable which holds a reference to
> some data. And call by object reference gives the called method read
> access to a reference to an object. The called routine can NOT change
> the reference, it can only invoke methods on the referenced object.
>
> Note that although Ruby does allow assignment to a parameter
> 'variable' this is only moving a 'sticky note' to use Austin Z's nice
> analogy.
>
That's pretty much how I feel things are, if "call by object
reference" is used in the Smalltalk community I see no obvious reason
why not to steal it ;). Ruby and Smalltalk do share the parameter
passing semantics after all.

Completely agree. +1 for "call by object reference". What a wonderful
resolution: two options were debunked and a third alternative is
chosen as the winner. :slight_smile:

A side remark to Robert's witty remark about the "truth value and
number of supporters". This was really funny and a good defense, but
on the serious side, I honor the opinions of most of the lists
'regulars', even if I do not show it well all the time - which is bad
style from my part :(. (Comment ça va Xavier? :wink:

:slight_smile: As always, it was fun debating with you, Robert.

Kind regards

robert

···

2007/10/2, Robert Dober <robert.dober@gmail.com>:

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

20

<snip>
> Part of the problem with this whole discussion is that it's crossing
> meta-levels. Immediates/intrinsics exist in the implementation, below
> the language level. To the Java/Smalltalk/Ruby programmer the
> encoding of object references is invisible. Object references are
> object references.
Not for Java - we can not accept Java in the same league as Smalltalk
and Ruby can we ? ;).

Um, where's the problem? Java is a great language and it certainly
has its uses (helps to pay my bills for example). And don't forget
that several pieces of Ruby were inspired by Java (at least I believe
so).

While in Smalltalk and Ruby I can and shall handle a Fixnum as an
imutable object
in Java I cannot.
IIRC this fact is somehow hidden in version 1.5+ by some mechanism of
Autoboxing but I am not sure about that.

Immutability and PODs with autoboxing are different concepts. In all
Java versions (i.e. even prior to 1.5) java.lang.Integer and similar
/are/ immutable. In fact, with regard to calling semantics this is
the exact equivalent to Ruby. From a Ruby language user's perspective
immediate values are just an internal optimization that is irrelevant
for parameter passing modes. Rick nicely pointed this out.

Kind regards

robert

···

2007/10/5, Robert Dober <robert.dober@gmail.com>:

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