Reading byte array into float (expanding on SerialCallResponse example)

Yes, I do understand.
It seems to me that there are four distinct but related core issues that, when not explained together, contribute to and perpetuate the misunderstanding.

The first is a problem of semantics: ALL data items passed as arguments are “values” in that they are a copy of - the value - of the data items passed. The significance is in how that item is interpreted - i.e. what you can DO with that value. If it is a primitive, then it is merely a copy of - the value of - the original data item; and you can use the information contained in it, whereas if it is a pointer, then while it is still a copy of - the value of - the original data item - that original data item is a pointer to (“a means by which we gain direct access to”) another data object. So if we pass a pointer to a data item, we can reach across and manipulate the item to which the pointer points (I resist the temptation to say “refers”.)
So in fact, it doesn’t matter if the argument passed is a primitive or a pointer to a complex data item, then the original instance of that argument cannot be changed by the called function/method - the only thing that can be changed is the actual data item that argument points to, IF that argument is a pointer.

The second is the “new” command. Java is inconsistent in that to create a primitive variable one has only to declare the type and the name of the new item:

int myInt;

but for a complex data item, we use the “new” command to actually allocate the space…:

myThing = new Thing;

and in this case “myThing” is a pointer, a handle by means of which the new Thing may be manipulated (not an Apple “Handle” from back in the day - that’s a pointer to a pointer).
So if we say

Thing aThing;

we are creating only a pointer to a complex data item - a means by which we might manipulate some real complex data item inf the future - NOT an actual item. Old C or assembly language programmers like me need to make sure we’re not tripped up by that!

Anyway, when we pass “myThing” we are passing a copy of - the value of - the variable “myThing”, which is only a pointer, which refers to - gives us access to - the Thing data item we just created. If we pass “aThing”, then we are doing the same thing: passing only the the value of the pointer, except that in this case hasn’t been initialized to a real data item yet.

The third is our over-simplified English language. When we say “We can’t change what myThing points to”, or even “We can’t change the data item to which myThing points”, we are NOT necessarily saying “we can’t change the actual item to which myThing happens to be pointing”. Grammatically those expressions are NOT the same at all, but the first two are dangerously and ambiguously similar to the third, and it is anybody’s guess which of those two critically different meanings the reader will internalize when those words are spoken. It’s a classic “who’s on first”.

The fourth: the syntactical elements which are glaringly absent from Java. You cannot say

&myPassedValue

in Java; it is simply not allowed. You cannot “back up” and fiddle with the original of the passed value; and you cannot/have no need to say

*myPassedValue

because if it’s a primitive then that construct makes no sense, and if it isn’t then Java already knows to treat it as a pointer and to dereference it.

THAT, to me, is the core of the issue, and to simply label the problem as “by reference vs by value” is to miss the point.

2 Likes