Reference vs. Reference

[Rick DeNatale]

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,

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.

 

[Eric Mahurin]

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:

http://foldoc.org/?call-by-reference
...
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

 

[Rick DeNatale]

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.

 

[Robert Dober]

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

 

[Robert Klemme]

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

 

[Robert Dober]

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).

There was a Smiley Robert, however I feel that Smalltalk and Ruby are very much
in contrast to Java. Java is a nice tool but it is not a dynamic
language and it is not
pure OO. This might not be important for many, for me it is.

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.

Yup, maybe I missunderstood here, I was not talking about java.lang.Integer but
about int. Probably my error. What I wanted to clarify was that in
Java is int,bool etc which are not objects even on the language level.
It might however be that this is not related to the discussion as I
thought first.
Always good to talk it over

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.

As he often does but this time I seem to have it missread .
Robert

 

[Robert Klemme]

There was a Smiley Robert,

Yes, I know I know. But I'm sick of all the Java bashing around and
had to voice that at some point. <rant>I often get the impression
that some dynamic language adopters feel like they are the avantgarde
or elite and disregard other tools just because they are not the

however I feel that Smalltalk and Ruby are very much
in contrast to Java. Java is a nice tool but it is not a dynamic
language and it is not
pure OO. This might not be important for many, for me it is.

Admittedly it has it's advantages and actually this is one of the
reasons I love Ruby - everything is an object - period. There are no
exceptions and this is really great.

Kind regards

robert

 

[Xavier Noria]

Yup, maybe I missunderstood here, I was not talking about =20
java.lang.Integer but
about int. Probably my error. What I wanted to clarify was that in
Java is int,bool etc which are not objects even on the language level.

Yep, but that's not relevant to the kind of method call done by Java. =20=

The point is: no matter whether you have a primitive int or an object =20=

reference, in Java they are passed by value. The JLS says[*]:

When the method or constructor is invoked (=A715.12),
the values of the actual argument expressions initialize
newly created parameter variables, each of the declared
Type, before execution of the body of the method or
constructor.

-- fxn

[*] http://java.sun.com/docs/books/jls/third_edition/html/=20
classes.html#8.4.1=

 

[Robert Dober]

Yes, I know I know. But I'm sick of all the Java bashing around and
had to voice that at some point. <rant>I often get the impression
that some dynamic language adopters feel like they are the avantgarde
or elite and disregard other tools just because they are not the
newest / hottest / whatever.</rant> Note, I don't mean you - you just
happened to provide the trigger.

I prefer to be honest:

yes I feel that Smalltalk and Ruby are conceptional better than Java.
Java is a language that just is not at the same level.
It does not really satisfy the expression Very High Level, it is not
even half as expressive and elegant as S&R.
I do not feel I bash Java, I just think it is a different thing and overrated.
I am aware that this opinion might hurt some feelings and that is why I kind
of held back. But I guess you have seen through me Robert so I better confess
right away.


Robert

 

[Paul Brannan]

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:

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

Paul

 

[Eric Mahurin]

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.

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

 

[Robert Klemme]

Perhaps I wasn't clear. I meant:

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

 

[MenTaLguY]

--=-hN2kha2YMMAuWGMURUwB
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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.

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


--=-hN2kha2YMMAuWGMURUwB
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD4DBQBHBkWcSuZBmZzm14ERAvxgAJd1mj+86ZZLNpFFXRGEqXxwa3jUAKCnrRcL
hjTvYeZ8/cPrOwPp3xbwuQ==
=FDtZ
-----END PGP SIGNATURE-----

--=-hN2kha2YMMAuWGMURUwB--

 

[Paul Brannan]

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

Your comment indicates you thought I meant:

not the address of the variable but the object (or a copy of the
object) itself

when I really meant:

not the address of the variable but rather the address of the object

and had over-simplified it to something like:

not the address of the variable but the object

which is syntactically ambiguous.

Paul