pass by reference

[Arved Sandstrom]

By the way, this is also true for "reference" itself. They also have
to learn that what Java calls a reference wouldn't be called that way
in other languages, for exactly the reasons you wrote (null allowed,
assignment-semantics).

Hey, one's mind can get bent in new and wonderful ways. When I encountered
nullable value types in C# there's no question but that I scratched my head
a bit, particularly since before that I kept on reading statements like "a
struct instance cannot be null". Finding out that I could circumvent this
little annoyance by having nullable structs was eye-opening. Admittedly
a very handy feature.

Why is it ok, to talk of references in Java, but have an entirely
different meaning of "reference" in mind in context of the phrase
"pass by reference"?

Because one "reference" is an object reference, and the other means passing
the address of something, but since we're not passing the address of the
reference...

I deduced my liberty to "redefine" "pass by ref" from Java's liberty
to redefine "reference" in the first place. My redefinition of
it was coined on java's vocabulary: Objects are not passed directly
(as possible in C++, where the whole structure of the object gets
dumped on the stack), but "through use of (Java-)references".
This is natural language as I understand it.

Natural language (computer science, but not language-specific) is that a
reference contains information referring to data stored elsewhere (the
referent). This may be accomplished with raw addresses or otherwise. AFAIK
Java and C# use handles (pointers to pointers), something quite familiar to
anyone who did lots of Macintosh programming back in the day. I stand to be
corrected if Java object references are not handles.

AHS

 

[Patricia Shanahan]

Andreas Leitgeb wrote:
....

Because this redirects mental focus from Objects to the references,
which I consider a less worthy goal, than you seem to do.

....

I think focus on references is key to understanding and predicting Java
behavior. There are a lot of things in Java that make perfect sense in a
reference-orientated model, but seem rather strange and arbitrary in
terms of objects.

Patricia

 

[Andreas Leitgeb]

In programming language design, the term pass by reference
properly means that when an argument is passed to a
function, the invoked function gets a reference to the
original value, not a copy of its value.

Compilers are bright. They accept lvalues for rvalues, and
know how to retrieve the (rvalue-shaped) content from the lvalue:
int i=42, j= i +1; i=43;
in "i+1" it sees, that it uses the address only to obtain the
value, whereas in "i=43", it needs to do something completely
different with "i". (iload vs. istore or getfield vs. putfield)

People (those who follow the discussed model) are just as adaptive:
They know, when they have the variable in mind (as an lvalue),
and when they intend to identify the object with the reference.
(for the time until re-assignment of the reference)

With the mental model "Only objects are passed by ref", it's
clear, that since the variable is not an object, it will not
be "passed by ref" and changes to the variable in the callee
will not reflect back. At the same time, focussing on the
objects and treating the variables as readonly (after the
object is first assigned to them) gives exactly the effect
expected from "call by ref" - of course only on the objects.

The disadvantage of this model is, that it is incompatible
with language-police-type defenders of "the one and only
standard java-model".

The advantage is, that thinking of passing Objects (which the
other model says is impossible) saves up those all too sparse
"indirection-stack-levels" in human brain.

Anyway, I shall never again say, that "java did call by ref for
objects", but more like this: "one could see it as passing
objects by ref, as long as one avoids reference-assignments
inside the callee".

PS:
The object-oriented, rather than variable-oriented, "swap":

interface Assignable {
public Assignable createCopy();
public void assignFrom(Assignable src);
}
....
void swap(Assignable a, Assignable b) {
Assignable tmp=a.createCopy();
a.assignFrom(b); b.assignFrom(tmp);
}
....

 

[Andreas Leitgeb]

If I consider my *object* to be the parameter, then passing down
a java reference pointing to my object is just "providing the called
module with the address of my object". q.e.d.

In a more abstract sense, the "address" is any type of handle by which
the object is identifyable/addressable/reachable/....

Those who wish to claim what Java does is pass by reference, okay
with me, just remember this is a common certification question and
you must give the official answer when it comes up.

Fortunately one doesn't automatically fail the whole test just
for one question answered "wrongly".

Does anyone remember Fortran's pass by copy-back (or copy-reference)?
Or older, Algol W (I think) that used pass by name?

Tcl is another example. Basically it only supports call by value.
However such a value can be a string holding the name of a local
variable of the caller, and the callee invokes a tcl command that
links the named variable from caller scope to a callee-local variable.

set var "foo"
proc mod_by_ref {varName} { upvar $varName lcl; set lcl "bar" }
mod_by_ref var
puts $var ;# ---> prints: bar

Now, what's this? I call the procedure just with a value, namely
"var", so it's "call by value", but effectively, with help of that
"upvar" command, I get semantics of call by reference.

You won't be surprised that I had a similar discussion like this one
in comp.lang.tcl some time ago, again with people citing general
definitions of the whole "call-by-*" family (all the definitions
being not at all applicable to tcl, imho, except of course for
call-by-value, which is probably applicable in every language),
and claiming that the snippet above is anything but not "call by ref" ...
And I think it's even nearer to call-by-ref than Java, for which
call-by-ref is just a limited (but practical) model.

Above every language develops a super-language of idioms. Idioms
to mimick features not present in the base-language. Some of
these idioms are then simplified into new syntax, and the
result is C++ from C, or Java1.5 from Java-pre1.5. Many
features start as commonly used idioms. Not re-assigning
parameter references to mutable objects, or using mutable
container-objects (for otherwise immutable objects or for
primitives), is the idiom for "call-by-ref" in Java.

I'm personally quite happy with Java's pass by copy/value only!

Fine, I'm happy with my model, too.

 

[Andreas Leitgeb]

I thought I clearly explained that in C++ you can do modify objects in a
subprogram _both_ with pass by reference and with pass by value?

With the latter you mean "pass pointer by value"?
Yes, sure, but the example (in another sub-thread) specifically
used C++'s call-by-ref syntax, which under the hood still looks
like "pass pointer by value".

Consider the following
[example where pass-by-ref semantics are broken by doing a
re-assignment - however this time on caller's side]

It's simple: do not re-assign references, and as result you
get semantics for objects that are indistinguishable from
call-by-ref.

 

[Andreas Leitgeb]

I think focus on references is key to understanding and predicting Java
behavior. There are a lot of things in Java that make perfect sense in a
reference-orientated model, but seem rather strange and arbitrary in
terms of objects.

Java: an OO...? no! an RO (Reference Oriented) Language

 

[Chris Smith]

Arved Sandstrom wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

concept with a well-understood definition.

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Namely: the lvalue of the

formal parameter is the same as the lvalue of the actual parameter.

[ SNIP ]

Apparently not so well-understood, Chris, not if we (and tens of
thousands, and hundreds of thousands, and millions, of others) are
having this discussion.

Aye. I meant well-understood in the sense of it not being up for debate
or disagreement among the most knowledgeable people in the relevant
field. Sort of the way one might say (just to pick on something) that it
is well-understood that the finitely generated projective modules of a
purely infinite simple ring form a group with respect to the direct sum.
Sure, 99.999% of humanity has never heard of purely infinite simple
rings, finitely generated projective modules, or perhaps even groups.
Nevertheless, it is still well-understood.

And the fact is, "call/pass by value/reference" is _not_ something with
a well-understood definition, not when it comes to categorizing things
like "pass pointer by value".

It's certainly true that a lot of people are wrong about the meaning of
these terms. But if you do your research with textbooks on programming
languages (and I don't mean Java for Dummies), and in the words of
experts, you won't find the same thing. James Gosling has already been
quoted here. More language-agnostic sources will agree.

I myself am perfectly happy to use the more precise language to keep
Java people happy - it's no sweat off my back.

Sure, and to be fair, in a private conversation with someone who knows
programming fairly well already, I also wouldn't interrupt anyone to
start an argument over the proper meaning of pass by reference. But in a
forum where people go to learn a programming language, in a public
discussion that is *about* the meaning of pass by reference, I'll
continue to point out the right answer.

 

[Andreas Leitgeb]

If someone does use the term in a meaning different from the
meaning imposed by the Java Language Specification, Third
Edition and does not give his deviant definition - how should
one know what he intends the term to mean then, unless one is
able to read minds at distance?

I submit this one:
" »call by reference A call in which the calling module
" provides to the called module the addresses of the
" parameters to be passed.« (15.06.08)

I think we agree on these terms, but disagree on the definition
of the words used. Especially the "parameter" - you take it as
only the very lvalue that is literally written, but I take it more
abstractly as whatever chunk of information I want the called
module to deal with and possibly modify.

My interpretation of a "parameter" would even include the contents
of a file on disk, whose filename(the "address") I pass to the module
as a string.

In a language neutral definition of "call by reference", I just can't
see how picking a very concrete low-level definition of the
words "parameter" and "address" can be claimed to be the only one
reasonable.

 

[Andreas Leitgeb]

This is especially true of Java, where the low-level details of addresses can
vary in the face of HotSpot optimizations.

What? What? Can it be? Does this sounds like some sort of agreeing
to this particular point? Or are you implying that I could mean
low-level as even lower than "normal" Java level? I'm quite sure,
that the level of abstraction I have in mind is higher than what
Mr.Gosling had in mind when dogmatizing that Java had no call by
ref.

If I order a pizza on the phone, I pass my choice of pizza by value,
and "my house" by reference (I tell them the address of my house),
that will receive their product upon completion.
Equivalently, I tell them both my choice and my address by value.
Yes, equivalently.

 

[Andreas Leitgeb]

[Lew quoted a personal email]

[Lew quoted a personal email]

Since you didn't yet seem to know: It's generally considered
impolite to quote back *personal* email-replies to the news-
group.

 

[Andreas Leitgeb]

Since you didn't seem to know, it's considered impolite to send so-called
"personal" emails on a public topic.

I stand that I didn't know of any netiquette against mailing
replies about off-topic issues off-public. - The discussion
of what statements are insults or not *was* off-topic here.
I leave it to the others to judge the severity of our misdeeds.
I will not mail you any further private mails of that kind.

 

[Arved Sandstrom]

Arved Sandstrom wrote: [ SNIP ]

Point being, and I made another recent post to this effect, very many
people do understand the distinction between pass by value and pass by
reference, but also call "passing a pointer by value" passing by
reference. You can

Which is incorrect.

It's incorrect and imprecise in the context of this thread in this Java
newsgroup.

But this thread is not such a casual conversation. This thread is
specifically about the meaning of "pass by reference", therefore precision
is mandatory.

I have been converted to that position.

You should extend that to all aspects of professional discipline as a
programmer, not just Java.

Oh, I believe I do, Lew. I use as much precision of speech as is demanded in
a particular situation.

AHS

 

[timjowers]

Hi guys,

Thanks for all the answers, I'm kind of surprised that a simple
question got so many answers! is this statement correct:

Everything in Java are passed by value, in the case of an object, a
reference to the object is passed, which is a value too, updating the
fields in the reference does reflect the changes. anyway, maybe I
should not try to understand java in a C++ manner.

but i can't help, String is a object, so a reference should be the one
passed, and why we can not update the field in the String object? and
then where is the field of the String?

Angelo

Mostly correct Angelo. I say "Everything is passed by a value of a
reference". That's more like what you'd mean from the C concept of
"reference". The C concept of "reference" and "pointer" grow form a
microprocessor terminology. The Java "reference" is the same concept
as from SmallTalk. Or a "handle" in Windows/Win32. That is, do not
expect to be able to de-reference or do other pointer/reference
tricks. You are correct in your statement that all args are a ref but
some are to immutable types (e.g. String) so the JVM creates new
objects any time those are assigned. In that respect, a String is
like a String in Visual Basic.

In Java you wind up creating a container class and sticking stuff into
it. You also end up using alot more ArrayList/other ADT's. I.e. use
StringBuffer to pass to a method.

Best,
TimJowers