You're spending so much effort being right rather than communicate.
You're trying to prove that this scotsman is not a true scotsman. And fail to recognize that he is in fact a scotsman.
Rather than directly addressing the definition of reference. You run me in circles. First by saying I needed to use the words of the spec, then by saying those words aren't the same in this other spec.
I pull in a third-party which you completely ignore, probably because it doesn't match your true scotsman. You try to show me differences, even though I clearly demonstrated an understanding of the different semantics.
You can only accept being right and have no interest in communicating.
Had you accepted the words used in the Java spec I could have answered No to the question about the behavior of C.
C did use the word reference, but it was not trying to define a language construct, instead it was using the word to help explain the semantics of a pointer, this matches the definition provided by Wikipedia.
Java on the other hand is defining a language construct. It has different semantics then C++'s use with the same name.
So we have reference as a concept, reference as a language construct in Java, and reference as a language construct in C++. Thus in order to communicate we have to agree to which of these we mean.
I thought that you would use the one defined in the language spec since that is what requested at the start. When I realized you were not sticking to that requirement, I was able to pull in more language into the mix and see how you would contort your logic to make it seem that all of these uses are consistent (they are not). But I was sadly disappointed when you wouldn't even touch Wikipedia definition.
Since we are talking about pass-by-reference, it is the semantics of pass-by-reference that are significant.
If your definition of 'reference' is 'something that can be used to find something', then there will be nothing that is not a reference.
Have a string? I can use that to reference something .: strings are references!
Have an integer? I can use that to reference something .: integers are references!
Have anything? I can use that to reference something .: anything is a reference.
Which is the path down which you are going by claiming that pointers are references, because they can reference things, and therefore passing a pointer to something is passing that something by reference.
It's meaningless -- which is why I have kept bringing it back to the semantics required by pass-by-reference.
And why I started with your ask, to use the Java spec which does not define them as you have here. My point was that we never established an agreed and consistent definition for reference.
I never once saw you pull out a definition from your sources. Even definition I had to dig for and you would deflect because it wasn't the one you wanted.
And I talked about the Java spec, which defines "references values" (abbreviated sometimes to references).
These are not references in the sense of pass-by-value, as I've demonstrated many times above.
You might claim that they're references in the sense that anything can be used to refer to something else.
But that won't get you references with the semantics required by pass-by-reference, which means that you can't claim that passing one is pass-by-reference.
Let's just imagine that they were called "oranges" -- would you be claiming that passing an "orange" gave you pass-by-reference?
If not, then it's clear that this is simply due to being confused by a name choice.
Under that definition, no passing by oranges does not have the same semantics as pass by reference.
This however changes the subject to the parameters of the functions. I have been talking about the object for which the parameter refers. Could we stick with talking about the concept I'm actually trying to get across rather than introducing a introducing a different one.
Since pass by oranges is not a term used in the Java spec, could you describe the pass by oranges semantics using spec terms?
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
If you pass an address to a function then you have passed the int by reference.
C does not have pass-by-reference semantics and will not pass int by reference.
Java interacts with objects by reference. When you call a method you pass the object by reference.
Java does not have pass-by-reference semantics and will not pass an object reference by reference.
Passing an int * in C does not pass an int.
Right you're passing a reference to int.
No, you're passing the value of an int *.
You're spending so much effort being right rather than communicate.
You're trying to prove that this scotsman is not a true scotsman. And fail to recognize that he is in fact a scotsman.
Rather than directly addressing the definition of reference. You run me in circles. First by saying I needed to use the words of the spec, then by saying those words aren't the same in this other spec.
I pull in a third-party which you completely ignore, probably because it doesn't match your true scotsman. You try to show me differences, even though I clearly demonstrated an understanding of the different semantics.
You can only accept being right and have no interest in communicating.
Had you accepted the words used in the Java spec I could have answered No to the question about the behavior of C.
C did use the word reference, but it was not trying to define a language construct, instead it was using the word to help explain the semantics of a pointer, this matches the definition provided by Wikipedia.
Java on the other hand is defining a language construct. It has different semantics then C++'s use with the same name.
So we have reference as a concept, reference as a language construct in Java, and reference as a language construct in C++. Thus in order to communicate we have to agree to which of these we mean.
I thought that you would use the one defined in the language spec since that is what requested at the start. When I realized you were not sticking to that requirement, I was able to pull in more language into the mix and see how you would contort your logic to make it seem that all of these uses are consistent (they are not). But I was sadly disappointed when you wouldn't even touch Wikipedia definition.
Since we are talking about pass-by-reference, it is the semantics of pass-by-reference that are significant.
If your definition of 'reference' is 'something that can be used to find something', then there will be nothing that is not a reference.
Have a string? I can use that to reference something .: strings are references!
Have an integer? I can use that to reference something .: integers are references!
Have anything? I can use that to reference something .: anything is a reference.
Which is the path down which you are going by claiming that pointers are references, because they can reference things, and therefore passing a pointer to something is passing that something by reference.
It's meaningless -- which is why I have kept bringing it back to the semantics required by pass-by-reference.
And why I started with your ask, to use the Java spec which does not define them as you have here. My point was that we never established an agreed and consistent definition for reference.
I never once saw you pull out a definition from your sources. Even definition I had to dig for and you would deflect because it wasn't the one you wanted.
And I talked about the Java spec, which defines "references values" (abbreviated sometimes to references).
These are not references in the sense of pass-by-value, as I've demonstrated many times above.
You might claim that they're references in the sense that anything can be used to refer to something else.
But that won't get you references with the semantics required by pass-by-reference, which means that you can't claim that passing one is pass-by-reference.
Let's just imagine that they were called "oranges" -- would you be claiming that passing an "orange" gave you pass-by-reference?
If not, then it's clear that this is simply due to being confused by a name choice.
Let's try it.
"reference values (often just oranges)"
"All interactions with objects and array is by oranges, much like pointers in C."
Yep, I'd use it.
"Objects are pass by oranges and if C had them, it too would be pass by oranges."
Ok, and does pass-by-orange have pass-by-reference semantics, or does it have pass-by-value semantics? :)
Have we defined what we are discussing as passed and the definition of reference yet?
I've done so several times.
Here is the simplest requirement, again.
When passing by reference, modifying the parameter modifies the argument.
Under that definition, no passing by oranges does not have the same semantics as pass by reference.
This however changes the subject to the parameters of the functions. I have been talking about the object for which the parameter refers. Could we stick with talking about the concept I'm actually trying to get across rather than introducing a introducing a different one.
Since pass by oranges is not a term used in the Java spec, could you describe the pass by oranges semantics using spec terms?