Hacker News new | ask | show | jobs
by chi3 2974 days ago
Coming from C++, if "passing by pointer value" is considered "passing by value", then what is the opposite? Not passing at all? I mean, there's always going to be _some_ kind of value being passed?
3 comments

If you write foo(&a), both "you pass a by reference" and "you pass &a by value" are fair descriptions of what happens.

The confusion arises because Java doesn't explicitly distinguish between a and &a; if you write "Foo a = new Foo();" in Java, the behaviour is similar to "Foo *a = new Foo();" in C++. So if we ask how "a" is passed, is the "a" we're talking about the reference or the value?

Ah, I see the reasoning. I only did basic Java in university so I might be remembering incorrectly, but aren't variables storing non-primitive values called "References"?

Seems weird to me to say that Java "passes by value" when all objects being passed are actually references to objects.

> I only did basic Java in university so I might be remembering incorrectly, but aren't variables storing non-primitive values called "References"?

Technically yes, but since the language doesn't let you talk about references directly, the concept rarely comes up. Like, in theory you could say "a is a reference that refers to a value of type Foo", but people don't actually say that; they just say "a is of type Foo".

> Seems weird to me to say that Java "passes by value" when all objects being passed are actually references to objects.

Indeed, completely agreed.

You do see this kind of language in Clojure, where you can talk about a var separately from its value.
The pointer value is passed (which is a valid contention), but that is what it has been defined as for decades.
In C++, terms

    void f(Foo x); // pass-by-value
    void f(Foo* x); // pass-pointer-by-value
    void f(Foo& x); // pass-by-reference
In the last example, you aren't passing in a value, you are essentially creating an alias for some variable in the calling scope.
But it's still just a pointer underneath? It's more or less just syntactical sugar which makes it dereferenced it for you, and I'd argue that it only makes sense to use the phrase in certain contexts.

The only real difference between the last two is that the last one shouldn't be sent in as null, isn't it? The test in OPs artictle doesn't really make sense either, because you can switch the values using pointers as well.

My made-up term "pass-by-pointer-value" just emphasizes the fact that in Java, Python, and sundry other OOP languages, you are always passing around a pointer to an object, even if it is implicit. This is why e.g. equality usually checks object identity (pointer value) in these languages (Python being a notable exception).

C++ just forces you to be explicit about this, as others have pointed out.