Well the way I've always thought of it is that Java passes "references by value". Meaning the target method receives a _copy_ of the pointer, not the actual pointer. So the result of newing up the parameter inside the target method doesn't affect the original, because you're just making the pointer point to a NEW memory address. On the other hand, mutating the parameter WILL affect the original object, because a copy of a pointer still points to that object from the caller.
Yeah, it says that in one sentence while its the central point of confusion if you even want to call it that.
Instead it rants at length to somehow save definitions that are clearly not particularly helpful in a language like Java.
This article just reeks of this certain kind of socially inept, completely unhelpful attitude and technical pedantry that has infected mailinglists and IRC channels over the world. Actively trying to misunderstand people in an effort to expose their ignorance or unfamiliarity with intricacies of whatever language or tool they are trying to navigate.
Its a terrible habit up there with feigned surprise.
This is a very unjustified and overly harsh criticism. The article clearly presents real world confusion that can arise from not understanding that Java is not pass by reference. This can easily lead to wrong code. So it's not just pedantically insisting on some specific terminology, but highlighting the semantically differences between passing a reference (more precisely pointer) by value vs. 'real' pass by reference.
I think the confusion was largely created by the author. When he asserts that nothing in Java is passed by reference, he's using "reference" in the C++ sense. Then he says things like "references are passed by value", which uses "reference" in the Java sense.
We should be consistent in terminology. If we accept Sun's terminology, then objects are indeed passed by reference. If we're insisting on the more traditional C++ terminology, then Java has no references, only pointers.
The author recognizes the two meanings of "reference", but isn't sufficiently clear about which meaning he's using at a given time.
If you already know Java, you have no need to have Java's parameter passing mechanism explained to you.
If you don't know Java, and need an explanation, then you need one based on terminology that exists outside Java. Pass by value and pass by reference are concepts that predate and exist outside of Java, describing programming language semantics in a way where statements about different languages can be compared and contrasted, because they're not phrased in vocabulary specific to the language the statement is about.
Java passes all arguments by value.
The idea of overloading the term 'reference' to mean 'pointer', but without all the power you get from pointers in languages like C, has at this point grown far beyond Java. I don't think it's a logical muddying of the waters to use it in a phrase like "references are passed by value" when describing Java using terminology that exists outside of Java.
1) To say that Java "passes all arguments by value" implies astonishing behavior if one passes an object and calls a mutator on that object changes it everywhere else that reference is used. If it were truly passed by value, the target would get a _copy_ of the original. Which is NOT the case in Java. So this terminology is misleading!
2) An admittedly weaker argument you imply that a given Java developer has never looked at any other language that doesn't use Java's approach to parameter passing. That's a tiny, tiny audience, my friend.
Java objects are not value types; they're reference types. You're confusing your concepts. Specifically, you're conflating parameter passing semantics with reference type semantics. The problem with this conflation is that reference type semantics cover more situations than merely parameter passing, so when you conflate the two concepts, you miss out on the remaining bits. Consider this:
Foo x = new Foo();
x.setBar(42);
Foo y = x;
y.setBar(0);
assert(x.getBar() == 42); // fails! astonishing behaviour!
If the value of x was assigned to y, surely modifying y shouldn't affect x, right? That's what assignment does, it takes the value on the right and puts it in the location on the left, correct? So why on earth was x modified when we only called a mutator method on y?
To understand this, you need to know that Java objects are reference types. And this has nothing to do with parameter passing.
And once you understand reference type semantics, you don't need anything extra to understand parameter passing, because parameter passing in Java uses the same semantics as assignment: that is, the value of the actual parameter is copied into the formal parameter, just like values on the right of an assignment are copied into the locations on the left. It's pass by copy.
Java does pass all arguments by value. The issue is that you don't understand that the value of a Java object reference is the same as a C++ pointer, which means passing it by value into a function means simply that you've copied the pointer, nor the object, and mutating that object inside the function is simply following the pointer copy to the same pointed-to object, so the caller also sees the change.
Note that it you change the pointer (object reference) directly, instead of following it and mutating the pointed-to object, the caller would NOT see the change. Like "x = new Foo()" inside a routine would not change what was passed in at all.
But if Java was pass by reference, then things would act differently.
Please learn Java. It's not about not knowing other languages. It's about not knowing Java. This is all in the JLS.
"The issue is that you don't understand that the value of a Java object reference is the same as a C++ pointer"
A C++ pointer is a simple thing: an address within the program's address space. In an earlier response to a similar claim of yours, RayleyField pointed out that "In HotSpot references are double pointers (useful for moving GC), but in general it's up to JVM implementation." Certainly, if you dig into a Java reference, you will find an address that is analogous to a C++ pointer, but the same can be said of a C++ reference. Java references are not exactly equivalent to either C++ references or C++ pointers, and the statement that Java passes by value is not dependent on an arguable claim that Java references are more like C++ pointers than C++ references. This line of argument has just added to the confusion in these threads.
We are talking logically, not implementation details.
Logically, a C++ pointer and a Java object reference are nearly identical, as described and defined by their respective language standards. Independent of the implementation chosen.
This is not the same as a C++ reference, which is logically an alias (and may be implemented via pointers, but that's irrelevant).
The confusion in this thread stems from people confusing many things, indeed.
If "we" are talking logically, then "we" should not be using the expression "C++ pointer" in the statement I quoted earlier. Doing so can only lead to confusion in the minds of people struggling to understand Java argument-passing.
'If we can't discuss this topic using those well-defined things, what can we use?'
I am told you will find all the things you need well-defined in the JLE, and in doing so you will avoid positing a plurality without necessity, as Billy Ockham may or may not have put it.
JLE? Or JLS? If you mean the spec (JLS) then I agree, you can find everything there. Including what I wrote above - that "Java object references" are the same thing as "Java pointers" (both in the JLS). The JLS also describes parameter passing in excruciating detail, and it matches the definition of "pass-by-value" (not "pass-by-reference") exactly.
But if people in this thread could read and understand the JLS, this thread wouldn't exist. Since it does, some of us feel like we should contribute and correct the false statements we see.
The well-definedness of 'C++ pointer' is a non sequitur - it is not a sufficient condition to justify its use in this context. 'Backwardation' is well-defined, yet I doubt it can contribute anything to this discussion.
Dude. I've been using Java since 1.0. You're talking about Java from the perspective of C++, which is confusing to someone who is actually programming in the Java language.
If we're using the "reference type" meaning of reference, then the phrase "objects are passed by reference" is grammatical nonsense. At best it becomes a tautology - "reference types are passed as reference types". What does that even mean? That reference types don't magically become value types when you pass them in as arguments? That doesn't actually say anything useful about the evaluation strategy.
There are differences. References in C++ are aliases. References in Java are pointers. C++ lets you pass-by-reference (meaning aliasing) or pass-by-value (including objects, pointers, ints, etc). Java only lets you pass-by-value (object references, ints, etc. There are no object values in Java, so those can't be passed at all).
Correctness is indeed important, which is why I wrote 'for the purposes of this discussion.' The topic of the original article is what Java does, and additional capabilities in C++ are not pertinent. Dlubarov posited that the author has sown confusion by using the term 'reference' in a C++-specific way, but I believe that confusion arises from a misreading of the article.
The phrases "pass-by-reference" and "object reference" need to be (and are) well-defined for the purposes of this discussion and for Java as it stands alone separate from C++.
But also, for the purposes of this discussion, it is very useful and illustrative to equate pass-by-reference to C++ references, and object references to C++ pointers, because the languages are similar and the concepts match up very well, and because these things are more explicit in C++.
Sure, one could have defined everything without comparing to C++ (in fact that is what the JLS does) but, for the purposes of this discussion, many of us assumed that wasn't good enough for many posters here, because if it was, this discussion wouldn't exist.
You are, of course, entitled to your opinion that the best way to clear this up is by making comparisons to C++, but the problem is that in defending your comparisons, you have brought in various issues, such as that C++ references cannot be rebound and the differences between the meaning of 'pointer' in the two contexts, that can be dispensed with if you do not take this approach. Personally, I think that those people who are both confused and looking at this from a C++ perspective would be better advised to stop making comparisons and look at Java for what it is.
Clearly reading the JLS wasn't good enough for most people. So what do you turn to when people take a well-established programming term like "pass-by-reference" and apply it where it doesn't belong?
Seems to me like a good place is a modern, widely-used language which is similar to Java but also has both pass-by-value and pass-by-reference so one can illustrate what those terms actually mean and how they differ.
Seems like C++ is as good a choice as any
Feel free to use another language if you can do better.
Explaining pass-by-reference using Java, which can't express pass-by-reference, is one of the sources of the confusion people here are experiencing (the other is Java using reference to mean something different from established meanings).
"Clearly reading the JLS wasn't good enough for most people. So what do you turn to when people take a well-established programming term like "pass-by-reference" and apply it where it doesn't belong?"
Clearly, one should turn to computer science fundamentals. Considering the totality of your posts under this article and the responses to them, picking the language with arguably the most complex panoply of ways to denote values, of any language in common use, hasn't worked out as a pedagogical device.
Clearly, others in this thread need something more accessible than computer science fundamentals. I believe, if that were enough, they would have understood the terms correctly from the start (because the terms are rooted in computer science fundamentals - the confusion only arises once you confuse them with Java terminology).
So do not conflate what you consider clear with what the thread is reflecting as clear. They are quite different.
I think you are being naive if you think people who don't understand the definitions of "pass-by-value" and "pass-by-reference" (terms well-defined and well-understood in programming language theory and computer science fundamentals), and then go on to further misunderstand an article about Java and C++, will get any benefit from discussion on the topic that avoids Java, C++, or any other concrete examples, and instead tries to use the very definitions themselves (which are not understood, remember?) to try to provide clarity.
As I said before, if people understood the fundamentals, or if the fundamentals were good enough, then this entire thread wouldn't exist. This stuff is child's play. Anyone who is confused by this needs more help than shrugging and saying "stop trying, just point them at more fundamentals"...
You appear to have put this post in the wrong place, as it says nothing that relates to the observation presented in the parent, which is that elsewhere, you ultimately abandoned your C++-analogy approach in favor of one that discusses Java in Java terms -e.g. 'Read the JLS. This is Java as defined by its creators, absent of C++.'
Which is not to say that there is anywhere this post belongs, as you attempt to use a couple of tired old rhetorical ploys: insinuating a position that has not been stated, and the insertion of a specific item into a list of disjunctions in the hope of insinuating that it is necessary.
Your argument here depends on the misunderstanding that all explanations in computer science are abstract, and specifically that they are inevitably more abstract than a discussion of the same topic in C++. That is not so; a discussion of argument-passing can be (and is) done in terms of addresses and stack frames. That's more concrete than 'abstract pointers', and also more straightforward than making qualified analogies between elements of Java and C++, which are of no help to anyone who doesn't have a solid understanding of C++, anyway.
This is just as well, or how else would anyone have understood this stuff before they had C++?
> you attempt to use a couple of tired old rhetorical ploys
I do no such thing.
> Your argument here depends on the misunderstanding that all explanations in computer science are abstract
Not at all.
> That is not so; a discussion of argument-passing can be (and is) done in terms of addresses and stack frames.
Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all. Neither is ideal.
> are of no help to anyone who doesn't have a solid understanding of C++, anyway
You just need a basic understanding. This isn't advanced stuff here. People learn Java's object references the very first time they
Thing x = y; y->something(); // Why has x changed?
and they learn C++ references and pointers ... well from the start.
These are week-one concepts for anyone learning the languages.
> This is just as well, or how else would anyone have understood this stuff before they had C++?
Most people have no trouble understanding the concept in week one of Java, or C++, or whatever other language they are learning. And the rest get it from the fundamentals. But those aren't the people in this thread who continue to confuse the issue.
If someone can't take the phrase "pass-by-reference" and the phrase "Java object reference" and understand that the two uses of the word "reference" mean different things, even after reading the simple-to-understand definitions of each, then they really need above-and-beyond help. This isn't "dive into CS theory" or "show them the machine-level stack frames and register contents", this is "try whatever you can that might help them". C++ is a very valid place to go for these folks.
Good day to you, too! You haven't disappointed in the latest of your daily diatribes!
'What in the world are you talking about?'
Here we have another common rhetorical ploy, the attempt to insinuate that the other party is not making sense, without actually refuting her arguments. If not used carefully, however, it has the unfortunate side-effect of giving the impression that you alone cannot figure it out.
But do keep the snide asides coming (not that I think you are likely to stop). If it were not for them, I would have left this thread long ago, satisfied that we had reached an amicable agreement to disagree.
You follow with a few flat denials of things I wrote. You can do that until the cows come home, but unless you can offer actual refutations of the arguments I presented in support of those claims, you are just blowing hot air.
'Sure you could do it that way. But it becomes exponentially more complicated because you need to either stick to one specific implementation of one specific language runtime, or you have to deal with explaining them all.'
Now we come to something that has the verisimilitude of a rational argument, and we can immediately see why you were reluctant to go there, despite the manifest failings of the alternatives you tried. The first question that comes to mind is, exponential in what? What, precisely, leads to an exponential growth in complexity? Note that the sentence quoted here claims exponentially more complication even if you stick to one specific implementation of one specific language runtime, so make sure that your explanation covers that case, or I will have to return to it. Also make sure that your explanation somehow avoids applying to C++, and covers how we ever managed to figure this all out before we had C++.
Furthermore, the implication that it has to be presented using one extant runtime or another is fallacious. One can discuss argument passing using stack frames and addresses without getting into how C++ or any other specific language implements it, and the empirical proof of that can be found in any number of elementary comp. sci. textbooks.
Your 'its so simple' argument is a non-sequitur, as you are making the fallacy that if the concept is simple, then any explanation will be simple. In reality people can, and do, tie themselves in knots over simple issues - Zeno's paradoxes are a case in point. In fact, the simplicity argument goes against you - it's so simple, yet you ended up retroactively qualifying your use of pointer as 'abstract pointer' and spend time in drawing analogies between C++ pointers and Java references.
And if its so simple, how come that there are people who are just not getting it? Maybe, just maybe, the problem is in how it is presented.
The question of whether an approach via C++ is helpful, and whether your particular approach (using qualified analogies between C++ and Java) helps, are separate issues. I could go into how well your approach worked in practice, though I don't think that is necessary at this point (unless you choose to go there), except to point out that you repeatedly abandoned this approach in favor of a purely Java one, telling people to 'read the JLS.'
I didn't even bring up C++ - the article did, dlubarov commented about it, and you asserted that C++ references and Java references were the same. That's where I joined - to correct your fallacy.
Perhaps it really is simple, and you are afraid to admit that maybe you didn't get a simple concept either, until your eyes were opened by the very posts you spend walls of text refuting. I know it is not a pleasant feeling, but it's acceptable to own up to it. No amount of text or thesaurus consultation will fix your mistake.
Or, if that's too much pride for you to abandon, then you can continue to stand behind your original claim that references in C++ and Java are the same for this discussion (or any other - but I posit that there is no discussion, except for maybe "the word reference in both phrases has the same spelling"), then I feel for you. I really do.
You were correct on the references issue (which was not as you present it here, which is typical), but mistaken over the cause of length of this thread, which comes from an unbroken series of faulty arguments you presented in an attempt to support the notion that using C++ was the only option in explaining the issue. The last one was a risible claim about the literally exponential complexity of the alternatives.
So here's a difference between us: I freely acknowledge correct arguments, while you silently slink away from your mistakes, and try to pretend you never made them. I am happy to have third parties figure out who is being immature here.
I also don't believe I ever claimed that C++ was the option.
I own up to my mistakes the instant they are apparent. If you believe I should be owning up to something but I haven't yet, it is because either I wasn't wrong, or the argument against me wasn't coherent.
But at least you finally capitulated. I didn't think you would, so you at least proved me wrong there.
I am hugely amused that you just could not resist making a statement that proves it is you who suffers from the obsession you accuse me of (not that there was any real doubt.) You remind me of the child who just cannot resist the marshmallow: https://www.youtube.com/watch?v=0mWc1Y2dpmY
In HotSpot references are double pointers (useful for moving GC), but in general it's up to JVM implementation. Pointers are one form of references, which are usually understood as machine addresses, but not all references have to be pointers.
We aren't taking about implementation details when we talk about object references being pointers in Java. It is actually the language level terminology that is correct to use absent of any specific implementation. See the JLS.
I've never seen actual bugs due to a misunderstanding of the concept though. It seem to be mostly a terminology difference between c++ and Java cultures. It is correct to say that Java passes objects as references, but it is technically wrong to say that Java is pass-by-reference. But since Java has only one way of passing objects, this terminology confusion does not lead to actual problems.
I agree it's bad habit, but I don't see it in the article.
The article goes to great length to argue why Java should use the same terminology as other languages. I would not say that the statements:
Sun wanted to push Java as a secure language, and one of Java's advantages was that it does not allow pointer arithmetic as C++ does.
They went so far as to try a different name for the concept, formally calling them "references". A big mistake and it's caused even more confusion in the process.
can be called "actively trying to misunderstand people". In fact it shows an understanding with the position he's arguing against.
One amusing artifact of that leaky abstraction is "java.lang.NullPointerException". How is that even possible, if Java doesn't have pointers under the hood?
There are no claims that Java doesn't use pointers. You just don't have direct access to them. Also i don't. Think the entire purpose was to hide pointers for correctness sake but to make the memory model consistent across plarforms.
You don't have to "actively try to misunderstand people" who confuse the meaning of the word "as" with the meaning of the word "by". They are confused about the precisely defined, widely understood meaning of words, and they already actively misunderstand the English language, as well as the Java language specification.
If I drove your grandmother BY a car, it would be totally different than driving her AS a car (logically: if your grandmother had wheels, then she'd be a car). In the same sense, passing the value of an object BY reference is totally different than passing a reference to an object AS a value.
Nobody's "actively trying to misunderstand people," because those people are already actively confused and insist on clinging to and spreading their shallow, incorrect definitions that directly contradict the Java language specification itself.
No matter how many times how many people patiently explain it to them in clear unambiguous terms, they still insist they're right and everyone else including the Java spec and James Gosling himself are wrong. Just look at all the ignorant postings in this thread by people like Mark Stock, Mark Hedley and Kevin Ryan, who just can't get it through their heads that they're wrong.
> Java passes "references by value". Meaning the target method receives a _copy_ of the pointer, not the actual pointer.
Which is exactly how C does it. I don't see how this is a difficult enough concept to grasp that we need an article explicitly pointing out how Java is just like C in this respect.
Not everyone knows C. A large percentage (maybe even the majority) of programmers who graduate from Java schools don't know C very well at all. For them, "it works just like C" is an insufficient explanation.
Or Asm, for that matter (likely even fewer programmers); at that level, basic concepts like memory addressing and pointers become almost "obvious facts of life".
As someone who started in Asm, I think pass-by-value/pass-by-reference are also intuitive there in the true "understood without needing any explanation" sense, since basically everything you'd pass to a procedure is a value of some sort, and it only depends on whether you are to interpret that value as a memory address.
> Or Asm, for that matter (likely even fewer programmers); at that level, basic concepts like memory addressing and pointers become almost "obvious facts of life".
In my intro-to-java-class, indirection was one of the first things we learnt when we learnt about objects: variables hold a reference to an object, not the object itself. I don't understand why pointers are somehow a great insight that is exclusive to lower-level programmers.
And if a java person ended up trying to make a method that swaps two primitive values, they'd have to learn about the distinction between passing a primitive value into a method as opposed to passing a reference to an object.
The problem is that most introductions stick with the primitives are pass by value, objects are pass by reference. Based on that introduction, they'd know you can't swap two primitives, but they'd think that you could swap two objects.
>I don't understand why pointers are somehow a great insight that is exclusive to lower-level programmers.
They're not. You don't need to be a lower level programmer to understand pointers, but it helps immensely if you know at least a bit of a low level language.
When you're getting into details like call-by-reference vs call-by-value, it really helps to have a mental model what the computer is doing. You don't need to be an assembly programmer, but it does help if you spend a little time studying assembly language.
Exactly. Objects in Java work just like objects in Python: pointers passed by value. The difference is that everything in Python is an object, whereas Java additionally has primitive types where the value itself is passed by value.
Because in C you have to specifically ask for something to be a pointer. "pass by reference" is an incorrect phrasing, but at least it's an attempt. There is a crucial distinction between Java and C.
In C, a pointer is a reference. It supports arithmetic, but it works like a reference as well, so the name applies.
What might confuse people is that in C, you do have to specifically ask for a reference to something, whereas in Java, everything which isn't a primitive type is already a reference.
It's true your code can't dereference those references such that it gets access to all of the data in a List object, for example. C works the same way, again: It's entirely possible to say something like 'typedef struct foo mfoo;' and then declare all of your functions to take pointers to type mfoo, and client code will never be able to get its hands on a struct foo object. FILE pointers work just like this, for example.
I don't think a pointer in C is really a reference though?
If you pass a pointer to a function, then you are saying, hey allocate a new variable to put on the stack which is a pointer. If you pass a reference, then at the language level, you are saying hey I want that function to use THIS variable that I already have. While the implementation may certainly be free to use a pointer, they are not fundamentally the same concepts.
A pointer in C is a reference (see ISO 9899:1999 § 6.2.5) under siege by nasal demons (see § 6.3.2.3). The implementation isn't really required to do many of the things people assume it is.
(It's ironic, by the way, that in seeking to be more pedantic, you reference stacks. Stacks are not part of C.)
A C pointer is not a reference in the way we are using the word reference in this discussion (as in pass-by-reference, as in an alias for another value without applying any operators).
Sure, the C standard uses the English word "reference", as in "refers to" and "referred to", but letting that confuse you without understanding the meaning of the word in context is what lead to this Java mess in the first place. Don't bring C into it too.
I'm not confused at all, thank you. I'm of the long-standing and well-informed opinion that "pass-by-reference" and "pass-by-value" are worthless terms that need to die, and that this entire conversation is an exercise in useless academic pedantry.
Based on your previous reply, you are indeed confused. Reference is a long-established term, and using it to refer to C pointers is typically considered incorrect.
In addition, pass-by-reference and pass-by-value are very useful terms for anyone interested in accurately speaking about and understanding what will happen when they run the program they write.
There are people who consider accuracy and understanding to be pedantry. More often than not, in my experience, they are a larger source of bugs than those who strive to truly understand how their tools work.
> Reference is a long-established term, and using it to refer to C pointers is typically considered incorrect.
I am not confused, I disagree.
> In addition, pass-by-reference and pass-by-value are very useful terms for anyone interested in accurately speaking about and understanding what will happen when they run the program they write.
The terms would be useful if people agreed on their meaning (they do not) and if languages actually followed one way or the other consistently (they do not). That is the very reason this thread exists.
If you wish to accurately speak about what will happen, then speak about it. Describe what actually happens, instead of spending your time arguing about which round hole the square peg fits in better.
> There are people who consider accuracy and understanding to be pedantry.
In practice, pass-by-value and pass-by-reference provide neither accuracy nor understanding. Stop using them, and these arguments instantly vanish.
> More often than not, in my experience, they are a larger source of bugs than those who strive to truly understand how their tools work.
That I strive to truly understand how my tools work is the very reason I reject these terms as worthless.
> The terms would be useful if people agreed on their meaning (they do not)
Most people agree on the meaning (read the JSL - it says Java is pass-by-value. Read Wikipedia too. Or really any other real reference that isn't some confused people in a forum.)
> If you wish to accurately speak about what will happen, then speak about it
That's what the article does. That's what the JSL does. People in these forums who still don't get it need something more. That's what I'm giving them.
> Most people agree on the meaning (read the JSL - it says Java is pass-by-value.
I assume you mean the JLS, in which case it -- very wisely -- does not use the term "pass-by-value" (or any similar term I've seen) to label its semantics. It simply describes its semantics.
> Read Wikipedia too. Or really any other real reference that isn't some confused people in a forum.)
So is it "most people" or a reference that, if anything, supports my point (JLS), an un-encyclopedia, and unspecified "real references" that aren't from people you enjoy insulting?
> That's what the article does.
That's one thing the article does, yes. Why is it you think you need to point that out?
> People in these forums who still don't get it need something more. That's what I'm giving them.
I agree you are giving people in this forum "something more". I suspect we disagree as to what that "something" is.
I haven't insulted anyone, have I? At least, not intentionally. No name-calling, sticking to the facts... I'm sorry if that somehow offends you. Some of us appreciate correctness and don't attribute the chase of it as ad hominem when it isn't.
If you don't understand how you're being insulting here, I can't help you.
> The JLS does define exactly what happens when parameters are passed...
Yes, it's very nice in that respect.
> And that happens to match the definition of pass-by-value/call-by-value exactly (even Java is listed as an example language for pass-by-value)
It happens to match the definition of "call-by-value" used by whoever wrote that blurb on Wikipedia you seem to love so much. The irony here, of course, is that people who like to use these terms don't even agree on how they're spelled...
If you google "pass-by-value" vs "pass-by-reference" and understand what they mean, in a language-agnostic way, and you understand what Java is doing when you pass parameters, then you too will come to the same conclusion and I have, and the people who wrote the wikipedia article, and everyone else.
If you like, though, feel free to provide your plethora of references and documentation that supports your claim that pass-by-reference is meaningless, and is also what Java does.
> If you don't understand how you're being insulting here, I can't help you.
There's no help needed. Asking someone to read and comprehend is no more insulting than pointing out where they are wrong. If being wrong insults you, then I suggest you refrain from posting misguided opinions in technical forums and standing by your incorrect position even in the face of overwhelming opposition from numerous sources.
If I was being insulting, I'd link you to the proggit thread and say "look, even proggit got it after a short discussion, why are the hacker news folks taking so long to get this simple concept"... but I haven't. Instead I would like to try to correct those who are mistaken. I feel like anyone who comes and reads the incorrect statements in threads like this should be able to then read the corrections so they too don't fall into the same traps you have.
> If you google "pass-by-value" vs "pass-by-reference" and understand what they mean, in a language-agnostic way, and you understand what Java is doing when you pass parameters, then you too will come to the same conclusion and I have, and the people who wrote the wikipedia article, and everyone else.
What conclusion would that be, exactly?
> your claim that pass-by-reference is meaningless
I didn't make that claim.
> and is also what Java does
I didn't make that claim, either. Nor would I ever. Stop putting words in my mouth.
> You did though. You claimed the terms were meaningless.
Just to be sure I didn't comment in my sleep, I went back and looked, and I see the word "meaningless" nowhere in my comments.
> But if you study, you find out they they have very specific meanings.
Some people have defined them in very specific ways. The description in the originally linked article is actually one of the ones I hate the least. That doesn't make it good, and doesn't make the terms useful.
> Calling C pointers "references" is just the tip of the misunderstanding iceberg.
What, precisely, will it take to convince you that I understand your position and simply disagree with it?
> I'm of the long-standing and well-informed opinion that "pass-by-reference" and "pass-by-value" are worthless terms that need to die
> The terms would be useful if people agreed on their meaning (they do not) and if languages actually followed one way or the other consistently (they do not).
Go read some actual literature about programming languages so you can get these ignorant notions out if your head.
The terms pass-by-value and pass-by-reference are well defined and have specific meanings both in the context of specific programming languages and independent of any specific programming language.
Pass by value means the value of the caller expression is logically copied in to the parameters, and direct mutations to the parameter itself are not reflected back to the caller.
Pass by reference means the opposite... The parameter is an alias for the caller's expression, and direct mutations are reflected back to the caller.
C pointers are not called references, except in an informal description of how they relate to what they refer to, by any authority on the topic.
I don't know if you are doing it intentionally or not but I'm done feeding your trolling. If you change your mind and want to learn anything else, my door is always open. But if you want to keep up this charade, whatever it is, go troll someone else. No one is going to read this thread this far down, so I feel no more obligation to correct your unfortunate misguided claims in the spirit of helping someone else who is actually looking for the right answer.
> If you change your mind and want to learn anything else, my door is always open.
I can't imagine what could lead you to think I'd be interested in "learning" from someone who clearly doesn't even understand what my claims/opinions are, but insists they're "ignorant" and "trolling".
What you've accomplished here is not to teach, but to harden my existing biases.
Even the best of us can't help the unhelpable. There has to be at least a basic willingness to listen and change.
But it's no skin of my back. My motivation was less about helping you (it was clear from the start that was probably futile) but to instead leave the right answers where you left wrong ones so others who are willing to learn can find what they need to succeed.
Ah good point about the stacks. However, I think the point still stands.. an argument being a pointer just defines its type, while an argument being a reference does not define its type, but that it's an alias to another variable.
Again, I think the issue is with terminology as someone else pointed out. Certainly a C pointer can be considered a reference when using the normal English definition of a reference, but "pass by reference" has a specific meaning, and in C you can't "pass by reference"
What something IS is independent of how you PASS it. An integer isn't a reference, but you can pass a reference to an integer in C++ (to implement swap, for example), while you can't do that in Java.
Well, he also has articles on tips for using Visual Age for Java, and a copyright notice starting in 1996, so perhaps this is yet another blast from the past that made it to HN's front page.
Because that particular argument used to be a thing.
The number of people who don't get it, or don't realize it is different from actual pass-by-reference and that the difference has actual consequences, is reason enough for an article.
In my experience, imprecise semantics and the misunderstandings that arise from them are a/the major cause of error, in both the requirements and implementation domains.
C has the address-of operator (&). So you can pass the address of a pointer, change what that points to in a function, and then the variable outside the function has indeed changed to point to a new chunk of memory. Java only has primitives and pointers to objects, and it only allows you to pass those by value to functions. You can't take the address of a primitive or object and pass that.
So basically in C you can pass an object (struct) or even primitive by reference... or at least you can fake it with trivial syntax. In Java you just cannot do that, and I think Java's use of the term "reference" to mean "pointer" makes some people (understandably) confused.
>You can't take the address of a primitive or object and pass that.
Not correct.
In Java, if you have an object you take the address and pass it. If you have a primitive, you pass a copy of the value. Both things are called "pass-by-value" (something that confuses a lot of people).
Java has no notion of "taking the address of an object" because you never have an expression that refers to an object directly. You only have the addresses, so there's no need (or way) to convert objects to their address.
And it's all pass by value (for all values you could have - numbers, addresses, booleans, whatever).
Heh, see why this is so confusing? That is of course what I meant -- it's really that Java, passing-wise, just has primitives and addresses to objects.
