pass by reference

java-programmer, pass by reference Andreas Leitgeb wrote:
> Patricia Shanahan <email***@***.com> wrote:
>> The issue is more critical for people for whom "pass by reference" is
>> familiar language. They will think they know what it means, and have to
>> find out somehow that it means something entirely different, when
>> talking about Java, that it does when talking about other languages.
>
> 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).

Indeed, I think the choice of "reference" to mean "pointer or null" was
a bad one. It would have been better to call a pointer a pointer, and
note that it can be null.

For the benefit of people transitioning from C or C++, it may be
necessary to note that it does not have pointer arithmetic or unsafe
conversions.

> 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"?

"pass by reference" (or more usually "call by reference") is a long
standing term with a meaning independent of the use of "reference" as a
freestanding term. I learned it long before I knew any language in which
one could actually have a reference. I don't see any reason why having
to learn a Java-specific meaning of reference should require people to
learn special meanings of other terms, especially when with have a
perfectly good phrase, "pass reference by value", that is only one word
longer and says *exactly* how Java behaves.

Patricia

java-programmer >> pass by reference Andreas Leitgeb wrote:
> Patricia Shanahan <email***@***.com> wrote:
>> The issue is more critical for people for whom "pass by reference" is
>> familiar language. They will think they know what it means, and have to
>> find out somehow that it means something entirely different, when
>> talking about Java, that it does when talking about other languages.
>
> 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).

Indeed, I think the choice of "reference" to mean "pointer or null" was
a bad one. It would have been better to call a pointer a pointer, and
note that it can be null.

For the benefit of people transitioning from C or C++, it may be
necessary to note that it does not have pointer arithmetic or unsafe
conversions.

> 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"?

"pass by reference" (or more usually "call by reference") is a long
standing term with a meaning independent of the use of "reference" as a
freestanding term. I learned it long before I knew any language in which
one could actually have a reference. I don't see any reason why having
to learn a Java-specific meaning of reference should require people to
learn special meanings of other terms, especially when with have a
perfectly good phrase, "pass reference by value", that is only one word
longer and says *exactly* how Java behaves.

Patricia

java-programmer >> pass by reference PreScriptum: By now, I've read most of the later posts, and my
focus has moved from insisting to use "by ref" in java-context
to understanding the technical difference in detail.

Chris Smith <email***@***.com> wrote:
> ... Pass by reference is a concept that has a particular meaning,
> independent of any other use of the word "reference" in a language.
> [...]

Then either the word "reference" also needs a particular meaning, or
the "pass by ref" is a cyclic definition, based on a meaning of
"reference" that is derived from that concept...

Most seem to agree to that whatever a reference actually is, it must
be one that references the *variable* (or lvalue) that was passed to
it. Also the non-null-ness of a reference seems to be quite agreed
on here.

I want to understand the crucial difference between C++'s
way and Java's way in those special situations, where their
technical effect coincides. There are of course other situations
where the difference is obvious, but I want to understand those
where it isn't.

If in C++ I've got a reference-parameter in a function f1, and pass this
reference(which refers to a real variable one call-level upstairs)
to another function f2 (again, by ref), then obviously f2 may modify
the actual variable two levels up (which was passed to f1), and *not*
modify the *reference* that lives in f1 and still refers to the actual
object "var" in the upper level, afterwards.
If there's a thinko in this paragraph, please point it out.
If it's just unclear, see the following C++ code snippet.

struct mystruct { int i; } var;
void f2(mystruct& x2) { x2=*(new mystruct()); }
void f1(mystruct& x1) { f2(x1); } // <--- x1 is not changed, only var is.
int main() { f1(var); }

* Is the call to f2 from within f1 really "by reference" ?
* Is "x1" (as argument to f2) actually an lvalue ?

If "x1" is just "seen" as an lvalue identical to "var", then
why cannot a java ref be "seen" as "identical" to the object
it points to? Just because it can be null?

f1(*(mystruct*)0); // is compileable! the inevitable runtime SIGSEGV
// only happens inside f2 at the assignment,
// f1 has no problem with a null-reference.

Just because Java-refs can be re-targetted by assignment?
Java's "." operator corresponds to C's "->" or: jRef.xyz == (*cPtr).xyz
If Java had an operator to tell an Object (addressed through the java-ref)
to assume another object's value (as happens when assigning to a C++
reference), would it do "pass by ref", then? IOW: does the difference
lie in the semantics of assignment?

> i.e., a reference in C++ is simply another symbol, with a possibly different
> scope, that denotes the same object as the symbol it is initialized from.

int x[10]; for (int i=0; i<10; i++) { int &j=x[i]; j=42; }
Ref j doesn't need to be initialized from a symbol.

As I've tried to show, most of the artefacts that are used to
disprove java's passing by reference, can be mimicked in C++
as well. The resolution of this contradiction can be either,
that "passing by ref" depends on more than just a method's
signature, or, that Java at least approaches some effects of
pass-by-ref quite closely.

java-programmer >> pass by reference "Peter Duniho" <email***@***.com> wrote in message
news:email***@***.com...
> On Sun, 06 Apr 2008 14:04:53 -0700, Andreas Leitgeb
> <email***@***.com> wrote:
>
>> [...]
>> There are times for exact language, and times where focus is on
>> other aspects. That's the other level I've kept mentioning.
>
> I really don't understand how you can, in a thread named "pass by
> reference", think that using the imprecise form of communication makes any
> sense whatsoever.

Mainly because very early in this thread one poster very clearly said:

"In java, all objects are passed by reference.

Basic data types like int, long, boolean are passed by value. Object
variables are always references to an object, and the reference is passed
"by value" as the basic data types, but it is a reference, so..."

Note the first sentence. You certainly can't say Java objects are passed by
value either.

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
call this imprecise...me myself, if I am satisfied that the person actually
understands that they are passing a pointer by value, and not a true
reference, don't lose sleep if they use the term "pass by reference".
Because what they mean is that they have a reference (a
pointer/handle/thingamajiggy) that points to the thing they want to access.
Not a C++-style reference, but a reference.

But when talking to Java folks I'll be very careful from now on. :-)

AHS

java-programmer >> pass by reference Andreas Leitgeb <email***@***.com> wrote:
> PreScriptum: By now, I've read most of the later posts, ...

Sidenote: of course I didn't travel to future :-)
I meant "later than this somewhat aged posting that I
was answering only now"...

java-programmer >> pass by reference "Stefan Ram" <email***@***.com> wrote in message
news:email***@***.com...
> Patricia Shanahan <email***@***.com> writes:
>>Remember you are discussing the subject "pass by reference" in a
>>newsgroup that includes people who are trying to learn how Java
>>parameter passing behaves.
>
> Let me add two quotations to this thread:
>
[ SNIP Gosling's quotation ]
> 籧all 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)
>
> 籧all by value A call in which the calling module provides
> to the called module the actual values of the parameters
> to be passed.?(15.06.09)
>
> ISO 2382-15, Information technology-Vocabulary-Part 15: Programming
> languages
>
> What the quotation from ISO 2382-15 calls 籶arameters?is
> being called 籥rguments?in Java.

This is all well and good. In practise what happens is that very many
programmers also take the case in which the parameter is a pointer, and the
value of that pointer is passed by value, to be call by reference. Not all
of those programmers understand that it's not call by reference in the true
sense, but enough of them do.

It's simply that there are several usages of the word "reference", and you
can't say that either is incorrect. In one sense a "reference" is a
handle/pointer to the thing of interest. IOW, I am calling by value, but I
still have a "reference" to the primitive/object that I wish to access
(including modify in the caller).

So far in this thread I haven't seen very many people contradict the fact
that Java is passing everything by value, in a technical sense. Some of us
are merely pointing out that one is still passing a "reference" to the
object...even if it is a copy of a pointer.

AHS

java-programmer >> pass by reference Lew <email***@***.com> wrote:
> Then we had really be extra careful not to spread misinformation, such as the
> canard that "call by reference" is somehow equivalent to "call by value with
> references".

I once came over to Java from C++. (and still do much in C++, even now)

I have C++-syntax in mind, like:

void foo(mystruct& r) {
if (r.field1) r.field2=42; else r.method(84);
otherfoo(r);
}

and when seeing Java source like:

class ... {
void foo(MyStruct r) {
if (r.field1) r.field2=42; else r.method(84);
otherFoo(r);
}
}

there is *some* temptation to think in C++ reference terms,
and accept reference-assignment as yet another exception to the
similarity (besides different library and other differences in
syntax), rather than as the killer evidence against my mental
model.

> Otherwise we do a huge disservice to those who wish to become
> (good) experienced programmers.

To me, this "canard" helped me quickstart into java. Only later
did I see the other mental model that explained assignment more
cleanly, but made my brain ache when I found myself losing my
grip on the algorithms for only thinking of "reference to this
and reference to that" instead of just "this and that".

Different mental models just happen, and sometimes alternative
models are not necessarily evil. Not more evil than different
human languages are, despite all the translation problems.

java-programmer >> pass by reference "Patricia Shanahan" <email***@***.com> wrote in message
news:ftbmf3$1bqv$email***@***.com...
> Andreas Leitgeb wrote:
>> Patricia Shanahan <email***@***.com> wrote:
>>> I came to my current position on this subject after viewing many
>>> articles reflecting parameter passing confusion, in this newsgroup and
>>> in comp.lang.java.help. I came to the conclusion that talking about pass
>>> by reference created a not unreasonable expectation of being able to
>>> change the value of a variable,
>>
>> This was, because "pass by reference" alone is indeed misleading.
>> I always wrote "passing *objects* by reference".
>
> Adding the word "objects" makes no sense at all, because there may not
> be any object. Null references can be perfectly valid actual arguments.
>
>>> What do you think is the main objective in selecting terminology to
>>> > describe Java parameter passing?
>>
>> The objective is, to explain some effect using a language that I think
>> the target knows. Natural language appears to me superior to a language
>> of technical terms with exact definitions from which only experienced
>> programmers can grasp all the subtleties.
>>
>
> Java learners can be divided, for this purpose, into two sets, those
> that already know what "pass by reference" means and those that don't.
>
> For those that don't, "pass by reference" and "pass reference by value"
> are both new language, and they might as well be told how Java really
> behaves.
>
> The issue is more critical for people for whom "pass by reference" is
> familiar language. They will think they know what it means, and have to
> find out somehow that it means something entirely different, when
> talking about Java, that it does when talking about other languages.
>
> Patricia

I certainly won't argue with any of the above. My first mainstream language
was FORTRAN, and the second was C. C++ came considerably later, and Java
much later than that. When using C (before any exposure to C++ or Java) I
and most everyone I knew used the term "pass by reference" when we were
doing "pass pointers by value", and by the very nature of what one normally
did with these pointers to the caller variables, there wasn't any confusion.

When first exposed to C++, I'll freely admit that for quite some time I
thought of references as "fixed pointers". Again, given what I did with
code, that concept never caused me problems. I knew I could change the state
of the referent inside the called code, and have that change be visible in
the calling code, and so forth.

Finally, when first exposed to Java (JDK 1.0.2) about ten years ago, I will
again freely admit that I thought of object references as "fixed pointers".
Since I normally don't write swap() functions, I don't think I for the
longest time ever really considered the difference between pass by reference
and pass pointer by value. Since in hindsight I almost always simply wanted
access inside the callee to the actual variable in the caller...something
that I did with passing pointers by value in C, either pointers by value or
references in C++, and object references by value in Java.

Pertaining to your last paragraph, I don't think it was until this same
subject (and also the "does Java have pointers?" subject) came up because of
Java, quite some years ago, that I truly consciously thought about the exact
differences. When I did understand the nuances, I can't honestly say that it
changed anything...I hadn't been running into problems with either C, C++ or
Java anyway. I don't recall that referring to "pass pointer by value" or
"pass object reference by value" as "pass by reference" ever caused me any
problems, anyhow. :-)

I don't have any problems with conceding that a more precise terminology is
best in a general discussion. It's just that a programmer who uses the term
"pass by reference" may be fully aware that they are "passing pointers by
value", and provided that he/she and his/her correspondents are on the same
sheet of music, I personally have no issue with that turn of phrase.

AHS

java-programmer >> pass by reference "Arved Sandstrom" <email***@***.com> writes:
>It's simply that there are several usages of the word "reference", and you
>can't say that either is incorrect.

In Java, I deem usages correct that agree with the definitions
and usages of the Java Language Specification, Third Edition.

If they do not, I also might deem them correct if the author
has given his deviant definition.

So they line is not drawn between one usage or another usage,
but between people who are being able and willing to give a
definition and cling to it and people who are not.

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?

java-programmer >> pass by reference "Andreas Leitgeb" <email***@***.com> wrote in message
news:email***@***.com...
> Patricia Shanahan <email***@***.com> wrote:
>> The issue is more critical for people for whom "pass by reference" is
>> familiar language. They will think they know what it means, and have to
>> find out somehow that it means something entirely different, when
>> talking about Java, that it does when talking about other languages.
>
> 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

java-programmer >> pass by reference 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

java-programmer >> pass by reference Stefan Ram <email***@***.com> quoted James Gosling:
> 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);
}
...

java-programmer >> pass by reference Wayne <email***@***.com> wrote:
>> 禄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)

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.

java-programmer >> pass by reference rmoldskr+email***@***.com <rmoldskr+email***@***.com> wrote:
> Andreas Leitgeb <email***@***.com> wrote:
>> Even in C++, I'm "merely able to modify objects in a subprogram", but in C++
>> it's still called "pass by reference".

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

java-programmer >> pass by reference 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.

--
Chris Smith

java-programmer >> pass by reference Arved Sandstrom wrote:
>> I myself am perfectly happy to use the more precise language to keep
>> Java people happy - it's no sweat off my back.

Chris Smith wrote:
> 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.

Right on!

I really don't understand the apologists for imprecision. Programming
requires precision; arguing for imprecision is contrary to the commitment to
excellence in programming.

--
Lew

java-programmer >> pass by reference "Peter Duniho" wrote:
>> I really don't understand how you can, in a thread named "pass by
>> reference", think that using the imprecise form of communication makes any
>> sense whatsoever.

Arved Sandstrom wrote:
> Mainly because very early in this thread one poster very clearly said:
>
> "In java, all objects are passed by reference.
>
> Basic data types like int, long, boolean are passed by value. Object
> variables are always references to an object, and the reference is passed
> "by value" as the basic data types, but it is a reference, so..."

> Note the first sentence.

That is true. However, the fact that the post you quoted is incorrect doesn't
justify the rest of us being careless.

> You certainly can't say Java objects are passed by value either.

The reason for that is that Java objects are not passed at all.

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

> call this imprecise...me myself, if I am satisfied that the person actually
> understands that they are passing a pointer by value, and not a true
> reference, don't lose sleep if they use the term "pass by reference".

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

> But when talking to Java folks I'll be very careful from now on. :-)

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

--
Lew

java-programmer >> pass by reference Andreas Leitgeb wrote:
> The disadvantage of this model is, that it is incompatible
> with language-police-type defenders of "the one and only
> standard java-model".

Ionteresting how you resort to name-calling when the people with whom you
disagree make an irrefutable case.

--
Lew

java-programmer >> pass by reference Andreas Leitgeb wrote:
> Patricia Shanahan <email***@***.com> wrote:
>> "pass by reference" (or more usually "call by reference") is a long
>> standing term with a meaning independent of the use of "reference" as a
>> freestanding term. I learned it long before I knew any language in which
>> one could actually have a reference.
>
> How many of the current java newbies do you think share your history
> of learning and previous knowledge?

How does that change the truth of what she says? Someone else's ignorance
cannot invalidate Patricia's knowledge.

> How many, in contrast, come from C++, and see the syntactical
> similarity (except for assignment) between Java's way of passing
> around references to Objects and C++'s way of passing objects
> (among other stuff) by reference?

They may be similar, but they aren't the same. You really are an apologist
for imprecision here.

>> I don't see any reason why having to learn a Java-specific meaning
>> of reference should require people to learn special meanings of other
>> terms,
>
> Because a substantial part of them doesn't know that general overall
> meaning of "pass by ref", and thus take it literally and thusly
> automatically in context with the "references" at hand in java.

And people who don't know the meaning of "assignment", they don't need to
learn the correct definition of that to be programmers either?

Programming is a *learned* art. You have to learn it. That means learning
the definitions of the terms - the *correct* definitions. Not having learned
it before is not a reason to refuse to learn it now. I should think that any
responsible programmer would be thrilled to learn the correct, precise
terminologies, instead of straining a muscle trying to argue against them.

> An archaic definition of the phrase without also a definition for
> the terms used in both the phrase and its definition, isn't all
> that shiny nowadays. Perhaps just like a green on black 80x24
> vt100 doesn't have the same exciting flair to everyone.

Now by calling a venerable term "archaic" do we hope to invalidate the correct
definition?

>> especially when with have a perfectly good phrase,
>> "pass reference by value", that is only one word
>> longer and says *exactly* how Java behaves.
>
> Because this redirects mental focus from Objects [sic] to the references,
> which I consider a less worthy goal, than you seem to do.

But that is the correct focus! It isn't about "considering it worthy" but
about accurately and precisely describing what's happening. When you pass a
parameter to a Java method, whatever your personal "mental focus" is will not
affect the reality of what is happening, which is that a method argument is
*never* an object in Java. If you are "mentally focusing" on objects as
method arguments, then you have misunderstood what is happening. It would
behoove you to shift your "mental focus" to the reality, however unworthy it
may be.

Again, simply applying pejoratives to the truth will not make it less true.

--
Lew

java-programmer >> pass by reference Stefan Ram <email***@***.com> wrote:
> 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.

java-programmer >> pass by reference Andreas Leitgeb wrote:
> 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.

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

--
Lew