pass by reference
angelo...@gmail.com
what is the equivalent of Java approach to this C++ function:
public void myFunc(String &s) {
s = "123";
}
I'd like to define a method where several values can be returned. any
idea?
Angelo
Donkey Hot
2e5b-44d3-b9b...@s13g2000prd.googlegroups.com:
public void myFunc(String s) {
s = "123";
}
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...
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>In java, all objects are passed by reference.
Nope. By value. See http://mindprod.com/jgloss/callbyvalue.html
--
Roedy Green Canadian Mind Products
The Java Glossary
http://mindprod.com
Roedy Green
<angelo...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>I'd like to define a method where several values can be returned. any
>idea?
1. you pass in an object, and you set fields on that object.
2. you create a new object with several fields and return that.
You can't change any of your caller's variables, just the fields in
the objects they point to.
rmoldsk...@online.no
This won't work, though. While the String object s' is passed by reference,
the _reference_ s is passed by value. Any changes made to the reference in
the subprogram -- such as changing the object it points to -- will not have
any effect on the main program.
public class Demo {
private static final STRING_1 = "String_1";
private static final STRING_2 = "String_2";
public void outer( ) {
String workString = STRING_1;
change( workString );
// workString is still pointing to STRING_1
}
public void change( String stringToChange ) {
stringToChange = STRING_2;
}
}
If the argument is a mutable type (unlike String), you can get the required
effect by modifying (rather than reassigning) the object:
public class Demo2 {
private static final STRING_1 = "String_1";
private static final STRING_2 = "String_2";
public void outer( ) {
StringBuffer workString = new StringBuffer( STRING_1 );
change1( workString );
// workString now equals "String_2"
change2( workString );
// workString _still_ equals "String_2"
}
public void change1( StringBuffer stringToChange ) {
stringToChange.delete( 0, stringToChange.length( ) );
stringToChange.append( STRING_2 );
}
public void change2( StringBuffer stringToChange ) {
// This won't work, as the change to the reference is
// lost when the method returns
stringToChange = new StringBuffer( STRING_1 );
}
} // end class
If you have an immutable type or need to create a whole new object for some
other reason, you'll need to use some kind of wrapper. Either a
data-structure or an array:
public void change( String[] stringWrapper ) {
stringWrapper[0] = STRING_2;
}
private static final class ChangeData {
public String toBeChanged;
}
public void change( ChangeData data ) {
data.toBeChanged = STRING_2;
}
--
Leif Roar Moldskred
Got Sfik?
Chase Preuninger
their value copied.
Andrea Francia
> On 04 Apr 2008 06:14:40 GMT, Donkey Hot <sp...@plc.is-a-geek.com>
> wrote, quoted or indirectly quoted someone who said :
>
>> In java, all objects are passed by reference.
>
> Nope. By value. See http://mindprod.com/jgloss/callbyvalue.html
Roedy is right, also a reference is passed by value.
void foo(Object ref) {
ref = b; // affect the sole method
}
Object ref = a; // ref points to same object that 'a' points.
foo(ref);
assert(ref==a); // ref still point to same object that 'a' points.
--
Andrea Francia
http://www.andreafrancia.it/
Andreas Leitgeb
> All objects are "passed by reference" and all primitive types have
> their value copied.
The objects are indeed passed by reference.
There is a fundamental difference between C++ and Java
with respect to the assignment-operator.
In C++, assignment is the Object's business,
so, passing an object into a function and assigning
to it inside, will change the value of that object,
and thus be visible outside.
In Java, assignment (with "="-operator) does not
change the referenced Object, but replace it, by
changing only the reference.
This effect, however, is not visible outside,
because it's only the Object, but not the reference
itself, that is passed "by ref".
Lew
> All objects are "passed by reference" and all primitive types have
> their value copied.
As others have stated and illustrated in this thread, that is not actually
accurate. That's why those quote marks, presumably.
In the sense that C++ programmers use "reference", Java objects are passed by
value, and the official word in Java is that references are passed by value
just as primitives are.
In any event, reassigning the formal parameter within a method does not change
the reference passed from the caller's point of view.
Stefan Ram provided good examples of idioms to handle the OP's need.
--
Lew
Lew
> Chase Preuninger <chasepr...@gmail.com> wrote:
>> All objects are "passed by reference" and all primitive types have
>> their value copied.
>
> The objects are indeed passed by reference.
When I took a practice certification exam in Java, I was marked wrong for
saying that objects are passed by reference. The fact is that objects are not
passed at all - references are, and they are passed by value.
--
Lew
Andreas Leitgeb
This indication of lingual hairsplitting perhaps explains, why I got
somewhat less than 100% for my SCJP (but still by far enough to pass).
Can't say for sure, since one is never told, which of the questions
were really answered wrongly.
Just as well one could say that nothing at all is passed (since methods
don't have arms or hands to pass things around), but only written to some
physical memory-location where it is then accessible to the called method...
and then we go on, that the jvm doesn't really "call" the method, because
the method doesn't have ears to hear any calling...(btw., "invoke" also has
an etymology that boils down to some form of akoustic communication.)
Really, this makes me sick.
Patricia Shanahan
I don't think this one is just hairsplitting. The "objects passed by
reference" model does not explain what happens when the actual argument
is a null reference. The actual behavior matches nicely the behavior
that predicted by the "references passed by value" model.
More generally, the "references passed by value" fits well with the
general observation that non-primitive expressions are all possibly-null
references, not objects. The actual argument is just a reference expression.
Patricia
angelo...@gmail.com
Thanks for all the answers, I'm kind of surprised that a simple
question got so many answers! is this statement correct:
Everything in Java are passed by value, in the case of an object, a
reference to the object is passed, which is a value too, updating the
fields in the reference does reflect the changes. anyway, maybe I
should not try to understand java in a C++ manner.
but i can't help, String is a object, so a reference should be the one
passed, and why we can not update the field in the String object? and
then where is the field of the String?
Angelo
Donkey Hot
60d2-4b7a-93c...@i36g2000prf.googlegroups.com:
> Hi guys,
>
> Thanks for all the answers, I'm kind of surprised that a simple
> question got so many answers! is this statement correct:
>
> Everything in Java are passed by value, in the case of an object, a
> reference to the object is passed, which is a value too, updating the
> fields in the reference does reflect the changes. anyway, maybe I
> should not try to understand java in a C++ manner.
>
> but i can't help, String is a object, so a reference should be the one
> passed, and why we can not update the field in the String object? and
> then where is the field of the String?
>
>
Yes, I was wrong in my
public void myFunc(String s) {
s = "123";
}
because that compiles exactly as
public void myFunc(String s) {
s = new String("123");
}
If the String class had a method setValue() we could write
public void myFunc(String s) {
s.setValue("123");
}
but it does not, and we can't.
Some kind of a wrapper class is needed with the methods required.
rmoldsk...@online.no
> Hi guys,
>
> Thanks for all the answers, I'm kind of surprised that a simple
> question got so many answers! is this statement correct:
>
> Everything in Java are passed by value, in the case of an object, a
> reference to the object is passed, which is a value too, updating the
> fields in the reference does reflect the changes. anyway, maybe I
> should not try to understand java in a C++ manner.
Think of it like this: Java has two different types of arguments,
fundamental values and references (similar to "smart pointers" in C++
terms). Both of these are copied by value.
Let's say you make the following two declarations:
int aNumber = 15;
String aString = "Hey!";
This will create three things in memory: an int with the value 15, a String
object with the value "Hey!" and a reference to the string object. Let's say
these are stored in memory addresses 0x1000, 0x2000 and 0x3000 respectively:
0x1000: 15
0x2000: "Hey!"
0x3000: ->0x2000
If you now make a call to a subroutine:
doStuff( aString, aNumber );
Local copies will be made of the int and of the reference, but not of the
object. Let's say these local copies are stored in 0x4000 and 0x5000:
0x1000: 15
0x2000: "Hey!"
0x3000: ->0x2000
0x4000: ->0x2000
0x5000: 15
If doStuff( ) looks like this, just before the method returns we'll have the
situation below:
private void doStuff( String aString, int aNumber ) {
aString = "Hello!";
aNumber = 20;
}
0x1000: 15
0x2000: "Hey!"
0x3000: ->0x2000
0x4000: ->0x6000
0x5000: 20
0x6000: "Hello!"
Then, once the local variables have been reclaimed, we'll be back to this:
0x1000: 15
0x2000: "Hey!"
0x3000: ->0x2000
(Well, 0x6000 will still contain the "Hello!" string until the next run of
the garbage collector, but we have no way of making use of it.)
--
Leif Roar Moldskred
RedGrittyBrick
Top-posting re-ordered - please don't top-post.
Its sort of correct but the language is a bit sloppy and open to
misinterpretation.
> anyway, maybe I
> should not try to understand java in a C++ manner.
I think you shouldn't. People who do seem to get confused.
> but i can't help,
Oh dear.
> String is a object,
Yes
> so a reference should be the one passed,
Yes, well a copy of the reference is passed.
> and why we can not update the field in the String object?
1) Strings don't have any public fields of the sort you imply.
2) Strings are immutable by definition.
Not all objects are immutable (obviously) but Strings are, by intention.
> and then where is the field of the String?
This isn't a meaningful question.
Consider ...
main() {
String x = "aaa";
foo(x);
}
static void foo(String s) {
String p = s; // ONE
s = "bbb" // TWO
}
There is an object of class String, having been instantiated it exists
somewhere in memory. Within this chunk of memory is (presumably) the
UCS-2 representation of the characters "aaa".
Just before assignment TWO there are at least three references that
"point" to this object. These three references have three names (x, s
and p). We can say that variables x,s and p contain a reference to the
same object. However s is a copy of x it isn't a reference or pointer to x.
If I were writing a JVM I might have structures not entirely unlike like
this:
After assignment "ONE":
addr contents
000 "x" 122 "s" 177 "p" 127
044 3 "aaa"
122 44
127 44
177 44
After assignment "TWO":
000 "x" 122 "s" 177 "p" 127
044 3 "aaa"
122 44
127 44
177 251
251 3 "bbb"
Notice that changing what s points to has no effect on what x points to.
I expect everyone will be glad I am not writing a JVM.
--
RGB
Wayne
> Roedy Green wrote:
>> On 04 Apr 2008 06:14:40 GMT, Donkey Hot <sp...@plc.is-a-geek.com>
>> wrote, quoted or indirectly quoted someone who said :
>>
>>> In java, all objects are passed by reference.
>>
>> Nope. By value. See http://mindprod.com/jgloss/callbyvalue.html
>
> Roedy is right, also a reference is passed by value.
Roedy is always right (almost). But I would state this differently:
objects are not passed at all in Java, and everything else
(including references to objects) is passed by value.
-Wayne
Mark Space
While a lot of the discussion here is pretty good, I think it missed the
fundamental point of giving the OP a simple answer.
public void myFunc( String [] sa )
{
sa[0] = "123";
}
In Java, all primitives are passed by value, as has been much discussed.
So you have to create a reference yourself, because there is is no
pass by reference available.
The most common pattern is just to use an array to pass the object
reference. The reference can then be replaced with another reference
and processed by the caller.
public static void main( String [] args )
{
String sb[] = { "456" };
myFunc( sb );
System.out.println( sb[0] );
}
It's a little hokey, but it works. Well except for the static context
.... make myFunc static for this example.
Not compiled....
Wayne
> but i can't help, String is a object, so a reference should be the one
> passed, and why we can not update the field in the String object? and
> then where is the field of the String?
Strings are immutable, read-only objects in Java. A read-write
String-like(say that 5 times fast) class is StringBuilder.
Strings need to be immutable for security reasons. (Imagine
a security monitor allowing some URL to be used, and later
that URL (stored as a String internally) to be modified.)
Java doesn't support the C++ notion of const, so for security
all the wrapper classes in Java.lang (Integer, String, Long, etc.)
are immutable.
For Strings Java provides StringBuilder (an unsynchronized version
of the earlier class StringBuffer) but for numbers there
are no defined read-write wrappers (say that 5 times fast).
Either you make your own wrappers or just use auto-boxing.
-Wayne (A "read write wrapper" rapper :-)
Roedy Green
<chasepr...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>All objects are "passed by reference" and all primitive types have
>their value copied.
The JLS is very clear on that. There is NO pass by reference in java.
Patricia argued persuasively some time ago why we should not muddle
the issue with talk of passing "objects by reference".
You can't pass objects in Java. You can in C, actually pushing the
entire object's contents to the stack.
In Java, you can pass a reference by value, however.
see http://mindprod.com/jgloss/callbyreference.html
http://mindprod.com/jgloss/callbyvalue.html
Roedy Green
<a...@gamma.logic.tuwien.ac.at> wrote, quoted or indirectly quoted
someone who said :
>
>The objects are indeed passed by reference.
The JLP smacks you down for claiming it does. Did you ever see the
Monty Python sketch about the Bulgarian-English phrase book?
Roedy Green
<angelo...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>but i can't help, String is a object, so a reference should be the one
>passed, and why we can not update the field in the String object? and
>then where is the field of the String?
The String class has no methods to change its internal fields. It is
immutable. So the callee, or anyone else that matter, can't change the
contents of a String object.
The caller has a local reference to the String. Java is designed so
the callee can't possibly change it. This was a language design
decision to create safer code based on years of experience with
languages that did allow it. You don't have to worry about side
effects of callees as much when reading code.
Roedy Green
wrote, quoted or indirectly quoted someone who said :
>Yes, I was wrong in my
>
> public void myFunc(String s) {
> s = "123";
> }
>
>because that compiles exactly as
>
> public void myFunc(String s) {
> s = new String("123");
> }
Not quite. The first points s to a string constant sitting in the
literal pool. The second pointlessly creates a copy of the string on
the heap and points s to that.
See http://mindprod.com/jgloss/newbie.html
Roedy Green
wrote, quoted or indirectly quoted someone who said :
> public void myFunc(String s) {
> s.setValue("123");
> }
>
>but it does not, and we can't.
>
>Some kind of a wrapper class is needed with the methods required.
you could invent a MutableString much like String with methods to let
you fiddle it. I would have a char[] internally. You would end up
with something very like StringBuilder.
see http://mindprod.com/jgloss/stringbuilder.html
Roedy Green
quoted or indirectly quoted someone who said :
>Local copies will be made of the int and of the reference, but not of the
>object. Let's say these local copies are stored in 0x4000 and 0x5000:
Another way of saying this that may make more sense to people with an
assembler, FORTH or other low level language background.
Primitive arguments are evaluated and pushed to the stack. References
to objects are pushed as 32 or 64 bit addresses/references to the
stack. The callee uses these much like local variables in its stack
frame, and pops them off and discards them on return. Thus changes to
the parameter variables are not reflected in the caller's variables.
Roedy Green
<mark...@sbc.global.net> wrote, quoted or indirectly quoted someone
who said :
>The most common pattern is just to use an array to pass the object
>reference.
it is also the most commonly frowned on approach.
Returning an Object[] of kitchen sink item is like using machine
language in terms of type safety and ensuring documentation on what
goes in which slot is accurate and up to date.
For any but one-shot programs, I try to avoid that technique. When
you have an IDE like IntelliJ Idea to crank out those piddly little
return classes, the temptation to use Object[] is not as great.
Another approach is to use separate methods to retrieve the results,
perhaps after a call to compute them.
Mark Space
> On Fri, 04 Apr 2008 10:02:50 -0700, Mark Space
> <mark...@sbc.global.net> wrote, quoted or indirectly quoted someone
> who said :
>
>> The most common pattern is just to use an array to pass the object
>> reference.
> it is also the most commonly frowned on approach.
>
> Returning an Object[] of kitchen sink item is like using machine
And here I could have sworn I used String, not Object.
Peter Duniho
<see_w...@mindprod.com.invalid> wrote:
> On Fri, 04 Apr 2008 10:02:50 -0700, Mark Space
> <mark...@sbc.global.net> wrote, quoted or indirectly quoted someone
> who said :
>
>> The most common pattern is just to use an array to pass the object
>> reference.
>
> it is also the most commonly frowned on approach.
Well, for better or worse, the Java SDK employs this exact approach for
this purpose. For example, see PathIterator.currentSegment(). If Java
had pass-by-reference, that would have been much better as a method that
returned the array of points, and set a by-reference integer parameter for
the segment type.
I agree it's not a great idiom, but it's all that Java offers short of
declaring a whole new class to contain parameters, since it doesn't do
pass-by-reference.
> [...]
> Another approach is to use separate methods to retrieve the results,
> perhaps after a call to compute them.
Eeeeewwwww. I would definitely pass an array before I did something ugly
like that.
Pete
Roedy Green
<angelo...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>I'd like to define a method where several values can be returned. any
>idea?
for four solutions, see http://mindprod.com/jgloss/multiplereturn.html
Roedy Green
<NpOeS...@nnowslpianmk.com> wrote, quoted or indirectly quoted
someone who said :
>> Another approach is to use separate methods to retrieve the results,
>> perhaps after a call to compute them.
>
>Eeeeewwwww. I would definitely pass an array before I did something ugly
>like that.
You could not do it otherwise for something as complex as Calendar.
Roedy Green
>And here I could have sworn I used String, not Object.
I discuss that at http://mindprod.com/jgloss//multiplereturn.html
Andreas Leitgeb
> Andreas Leitgeb wrote:
>> Lew <l...@lewscanon.com> wrote:
>>> Andreas Leitgeb wrote:
>>>> The objects are indeed passed by reference.
>>> The fact is that objects are not passed at all - references are,
>>> and they are passed by value.
>> Really, this makes me sick.
>
> I don't think this one is just hairsplitting. The "objects passed by
> reference" model does not explain what happens when the actual argument
> is a null reference.
It's a question of point of view. JLS & jvm's point of view is surely
the one you've claimed, namely of "references by value". One level
down, we have memory-locations and registers that are written and no
concept of "passing things" at all, whereas one level above we focus
on objects that we want to "pass" on to methods, not really caring
about the exact mechanics.
With "pass me the sugar please", one doesn't explicitly state that the
sugar is actually in a jar, and that it's really the jar that will be
(hopefully) handed back to the one who asked for it.
Andreas Leitgeb
> Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>>The objects are indeed passed by reference.
> The JLP smacks you down for claiming it does. Did you ever see the
> Monty Python sketch about the Bulgarian-English phrase book?
JLP? Google's first hit is "Jamaica Labour Party" :-)
I vill not bye diss record, because id is skredged!
Anyway, see my reply to Patricia's similar complaint.
Mark Space
> On Fri, 04 Apr 2008 11:50:18 -0700, Mark Space
> <mark...@sbc.global.net> wrote, quoted or indirectly quoted someone
> who said :
>
>> And here I could have sworn I used String, not Object.
>
> I discuss that at http://mindprod.com/jgloss//multiplereturn.html
The problem here is that you're still using Object, and you don't have too.
Here's my version of passing a String and an int for reference:
void myFunc( String [] s, int [] i )
{
s[0] = "a new String";
i[0] = 42;
}
This requires less unpacking than your example, and there's no
auto-boxing either.
It's still not as pretty as I'd like, but I think one should only make
objects when a design calls for it. If all you need to do is mutate
some random value, pass in an array.
That's different from the case where your design actually calls for a
mutable object.
public class EmployRecord {
private String name;
private int employID;
void setName( String s ) { name = s; }
void setID( int id ) { employID = id; }
}
void myFunc2( EmployRecord e )
{
e.setName("a new Name");
e.setID( 42 );
}
This is a totally different idea, even though functionally myFunc and
myFunc2 do the same things.
Mark Space
>> [...]
>> Another approach is to use separate methods to retrieve the results,
>> perhaps after a call to compute them.
>
> Eeeeewwwww. I would definitely pass an array before I did something
> ugly like that.
Java now has variable arguments, which are just syntactic sugar for an
array.
I wonder if it would be worth while to add some syntactic sure for
references too.
void myMethod2( String & s, int & i )
{
s = "a new String"; // passed back to caller
i = 42; // passed back to caller
}
The Java compiler would have to insert something like:
{ // Boilerplate
if( s == null || s.length != 1 )
throw new RuntimeException();
}
for each argument, and similarly substitute "s[0]" for each use of "s",
and pack and unpack the variables on the caller's side, but it would
work, and be less error prone than having to do it all yourself.
*shrug*
It's not like I do this a lot anyway, so I don't see how much it truly
matters. It seems like only C++ and C programmers who are brand new to
Java have issues with Java's version of pass-by-reference.
Roedy Green
>JLP? Google's first hit is "Jamaica Labour Party" :-)
oops JLS http://mindprod.com/jgloss/jls.html
Roedy Green
<see_w...@mindprod.com.invalid> wrote, quoted or indirectly quoted
someone who said :
>>And here I could have sworn I used String, not Object.
>
>I discuss that at http://mindprod.com/jgloss//multiplereturn.html
>--
oops I should have said
http://mindprod.com/jgloss/multiplereturn.html
Chris Smith
> With "pass me the sugar please", one doesn't explicitly state that the
> sugar is actually in a jar, and that it's really the jar that will be
> (hopefully) handed back to the one who asked for it.
Ah, but the problems arise when people try things precisely like the
example that started this thread. That is, try to write:
val = "New String";
and expect to see the changes in the calling stack frame. By the (fairly
universal) very definition of pass by reference, one would expect this to
work. One expects that using the formal parameter on the left-hand side
of an assignment will result in a change to the value of the actual
parameter.
That's not semantic games. It's a specific, observable, and testable
consequence that programmers would quite rightly expect from anything
called "pass by reference." In Java, it does not happen; therefore, it
is misleading to say "pass by reference" when talking about parameter
passing in Java.
There is certainly a higher-level view of what's going on. It's just
best to avoid using terms that have precise low-level meanings when
talking about things in terms of that higher-level view.
To belabor the point. Suppose, I had this:
public class Test
{
private HashMap m = new HashMap();
public static void change(String s)
{
m.put(s, "World");
}
public static void main(String[] args)
{
m.put("foo", "Hello");
change("foo");
System.out.println(m.get("foo"));
}
}
Is this an example of pass by reference? If so, does the term retain any
meaning at all any more? If not, how does this differ from calling the
earlier code pass by reference?
angelo...@gmail.com
I'd like to know more about this Intellij Idea and returned classes in
this case, any sample and use of Idea to achieve this?
Thanks,
On Apr 5, 2:48 am, Roedy Green <see_webs...@mindprod.com.invalid>
wrote:
> On Fri, 04 Apr 2008 10:02:50 -0700, Mark Space
> <marksp...@sbc.global.net> wrote, quoted or indirectly quoted someone
Peter Duniho
<see_w...@mindprod.com.invalid> wrote:
> On Fri, 04 Apr 2008 11:53:13 -0700, "Peter Duniho"
> <NpOeS...@nnowslpianmk.com> wrote, quoted or indirectly quoted
> someone who said :
>
>>> Another approach is to use separate methods to retrieve the results,
>>> perhaps after a call to compute them.
>>
>> Eeeeewwwww. I would definitely pass an array before I did something
>> ugly
>> like that.
>
> You could not do it otherwise for something as complex as Calendar.
I guess that depends on your interpretation of the original question. I
don't see that as equivalent to the scenario being discussed here, in
which you've got a class that's doing some computation on data that's not
part of the class itself. I find it perfectly natural to have the concept
of a class that has some internal state that you can affect through
calling of methods, and then you retrieve part or all of that state via
properties (even if Java's implementation of that is clumsy). I don't
disagree that that's a valid design in those cases.
But I don't see how that's similar to a scenario in which you'd want
parameters passed by reference. Passing parameters by reference for
something like that would just be silly, even in a language that supported
doing so.
Pete
Lew
> angelo...@gmail.com wrote:
>> but i can't help, String is a object, so a reference should be the one
>> passed, and why we can not update the field in the String object? and
>> then where is the field of the String?
>
> Strings are immutable, read-only objects in Java. A read-write
> String-like(say that 5 times fast) class is StringBuilder.
>
> Strings need to be immutable for security reasons. (Imagine
> a security monitor allowing some URL to be used, and later
> that URL (stored as a String internally) to be modified.)
> Java doesn't support the C++ notion of const, so for security
> all the wrapper classes in Java.lang (Integer, String, Long, etc.)
> are immutable.
Security is far from the only reason. Immutable objects are easier on
multi-threaded programming and easier for the JIT compiler to optimize.
--
Lew
angelo...@gmail.com
Thanks for all the answers, it is very educational, finally you guys
help a C++ turned Java newbie understands this 'pass by reference'
java way, conclusion is, it does not exist:), i have to think in Java,
anyway i finally find the solution: return a array of objects. thanks,
till next time:)
Angelo
On Apr 5, 7:51 am, Lew <l...@lewscanon.com> wrote:
> Wayne wrote:
Roedy Green
<angelo...@gmail.com> wrote, quoted or indirectly quoted someone
who said :
>I'd like to know more about this Intellij Idea and returned classes in
>this case, any sample and use of Idea to achieve this?
>Thanks,
It is just that intellij will let you compse a mini class very
quickly. It will build the constructor, getters and setters for you.
The final code is no different than you would write by hand, a
miniature holder class with fields for the various values you want to
return.
Arved Sandstrom
news:WpSdnSND4qHpiWva...@comcast.com...
> Andreas Leitgeb wrote:
>> Chase Preuninger <chasepr...@gmail.com> wrote:
>>> All objects are "passed by reference" and all primitive types have
>>> their value copied.
>>
>
> not passed at all - references are, and they are passed by value.
> Lew
I think the terminology is bad. I prefer to look at it from a practical
standpoint - can I take the pointer to the Java object (and a pointer it
is), pass it into a method, and make changes to the object pointed to from
within the method, in such a way that those changes are reflected outside
the method? Yes. I may get flunked on a certification exam, but I call that
passing the object by reference.
AHS
Lew
> I think the terminology is bad. I prefer to look at it from a practical
> standpoint - can I take the pointer to the Java object (and a pointer it
> is), pass it into a method, and make changes to the object pointed to from
> within the method, in such a way that those changes are reflected outside
> the method? Yes. I may get flunked on a certification exam, but I call that
> passing the object by reference.
Except that you aren't passing the object at all.
As Patricia Shanahan pointed out, thinking about this with the correct
terminology - Java method arguments are passed by value, and they are either
primitives or references - leads to more correct reasoning about and
predictions of program behavior. It's like Copernican astronomy - it's
actually perfectly valid to think of Earth as the center of the universe, but
the math is so much easier if you put it in orbit around the Sun.
--
Lew
Roedy Green
<asand...@accesswave.ca> wrote, quoted or indirectly quoted someone
who said :
>I may get flunked on a certification exam, but I call that
>passing the object by reference.
Language is for communication. If you use a word to mean something
different from everyone else does, you just create chaos when you
speak.
Andreas Leitgeb
> Andreas Leitgeb wrote:
>> With "pass me the sugar please", one doesn't explicitly state that the
>> sugar is actually in a jar, and that it's really the jar that will be
>> (hopefully) handed back to the one who asked for it.
> Ah, but the problems arise when people try things precisely like the
> example that started this thread. That is, try to write:
> val = "New String";
The only reason this doesn't work as they think, is because assignment
is always on the "pointer" and never on the whole Object.
Given a C-style pointer, one can (in C) either change the pointer, or
the pointed-to Object using assignment:
int i=42,j=84,*p=&i; // p is a pointer to i
*p = 43; // now "i" contains 43 (java has no pendant for that)
p = &j; // "i" is not touched, but p points to j now.
C++'s references behave like pointers that always have the
asterisk before them whenever used, thus the former of these
assignments.
Java can only re-assign "pointers", it cannot assign to the
pointed Object.
It isn't really necessary to resort to parameter passing to see the
difference.
> By the (fairly universal) very definition of pass by reference,
> one would expect this to work.
By the (at least as "very") definition of "reference" alone, one
might expect different behaviour of Java already. No matter if
it is passed or not. Java doesn't really have "references" the
way C++ has. Java's so called "references" really behave mostly
(but not entirely) like C's pointers.
The confusion comes from talking about "references" in Java in the
first place, not from how something is passed to methods.
> There is certainly a higher-level view of what's going on. It's just
> best to avoid using terms that have precise low-level meanings when
> talking about things in terms of that higher-level view.
I do see your point.
> To belabor the point. Suppose, I had this:
> [ example of a mutable Object that get's passed down
> into a function and modified there - as the Object
> was "passed by reference", the changes are still
> visible in the Object after the method returns]
> Is this an example of pass by reference?
From programmer's PoV it is. From JLS's it's not.
> If so, does the term retain any
> meaning at all any more?
Yes, at the programmer's level.
Btw., even in C++, which I think we agree does support
both by-value and by-ref passing of objects, really
passes on only "addresses by value" for that. Where
is the difference? The difference is in the semantics
of assignment.
Arved Sandstrom
news:fhqfv3tl9v507ngch...@4ax.com...
However, I don't think I mean "pass by reference" and "pass by value" as
anything other than the intuitive meanings:
a) pass by value - the method sees a copy of the parameter, whatever that
may be;
b) pass by reference - the method sees an alias to the parameter. If the
method uses the parameter it is using the actual thing referred to.
With objects Java does (b). I don't care if you call it "passing the
reference by value", or "passing a pointer", or whatever. If I do
Some Object so = new SomeObject(...);
makeChangesToFields(so);
then the fields in 'so' are changed outside the method. This is
pass-by-reference behaviour, not pass-by-value behaviour.
For the record I don't like the "swap" example that gets trotted out to
explain that Java is not pass-by-reference (as an example,
http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html).
It's disingenuous. If I write the same example using C++ with pointers to
objects, I get the same results...surprise, surprise.
AHS
Arved Sandstrom
> Arved Sandstrom wrote:
>> I think the terminology is bad. I prefer to look at it from a practical
>> standpoint - can I take the pointer to the Java object (and a pointer it
>> is), pass it into a method, and make changes to the object pointed to
>> from within the method, in such a way that those changes are reflected
>> outside the method? Yes. I may get flunked on a certification exam, but I
>> call that passing the object by reference.
>
> Except that you aren't passing the object at all.
No, but that's the common terminology. If I do pass by reference in C++ I'm
not passing the object either.
> As Patricia Shanahan pointed out, thinking about this with the correct
> terminology - Java method arguments are passed by value, and they are
> either primitives or references - leads to more correct reasoning about
> and predictions of program behavior. It's like Copernican astronomy -
> it's actually perfectly valid to think of Earth as the center of the
> universe, but the math is so much easier if you put it in orbit around the
> Sun.
I have absolutely no problem with that. We can get the C++ folks to also
adopt this perspective, since they are also just passing pointers/references
by value.
AHS
Andreas Leitgeb
> On Sat, 05 Apr 2008 12:01:49 GMT, "Arved Sandstrom"
>>passing the object by reference.
> Language is for communication. If you use a word to mean something
> different from everyone else does, you just create chaos when you
> speak.
Arved and me seem to agree that "pass objects by reference"
and "pass references (to objects) by value" are the same.
Those definitions of "by ref" that are quoted here imply
different results, only because they're based on a definition
of "reference" that is not the same as java's references.
Patricia Shanahan
> Roedy Green <see_w...@mindprod.com.invalid> wrote:
>> On Sat, 05 Apr 2008 12:01:49 GMT, "Arved Sandstrom"
>>> I may get flunked on a certification exam, but I call that
>>> passing the object by reference.
>> Language is for communication. If you use a word to mean something
>> different from everyone else does, you just create chaos when you
>> speak.
>
> Arved and me seem to agree that "pass objects by reference"
> and "pass references (to objects) by value" are the same.
How do you deal with null actual arguments? null is a fine value for a
Java reference, but is not an object.
In general, do you consider the value of an expression such as
new SomeClass()
to be an object, rather than a pointer to an object?
Patricia
Peter Duniho
<asand...@accesswave.ca> wrote:
> However, I don't think I mean "pass by reference" and "pass by value" as
> anything other than the intuitive meanings:
Your intuition seems to be broken. :)
> a) pass by value - the method sees a copy of the parameter, whatever that
> may be;
This is the only thing that Java does.
> b) pass by reference - the method sees an alias to the parameter. If the
> method uses the parameter it is using the actual thing referred to.
Java doesn't support this.
> With objects Java does (b). I don't care if you call it "passing the
> reference by value", or "passing a pointer", or whatever. If I do
With objects, Java still does a). The parameter is a variable that
references the object. It's not the object itself. And a copy of that
reference the variable holds is passed. If Java did support
pass-by-reference, and you passed an object reference "by reference", then
reassigning the reference would not change the original object, but rather
would change the variable that was pointing to (referencing) that object.
It's somewhat difficult to have this conversation in the context of Java,
since Java doesn't do "by-reference" parameter passing. However, C# does
and Jon Skeet wrote a pretty good article describing the business in that
context:
http://www.yoda.arachsys.com/csharp/parameters.html
The main difference between Java and C# in this situation is that C# does
in fact support pass by reference. Both languages have reference types
(in fact, in Java almost everything is a reference type and you can't make
your own value types), and in both languages parameters are passed by
value by default, including reference parameters. In C#, you can
additionally pass parameters by reference, including references.
If you insist on saying that passing a reference to an object is "passing
by reference", then what does it mean to pass a reference by reference, as
you can do in C# (and C++ for that matter)?
> Some Object so = new SomeObject(...);
> makeChangesToFields(so);
>
> then the fields in 'so' are changed outside the method. This is
> pass-by-reference behaviour, not pass-by-value behaviour.
No, it's not. You are passing a copy of the variable "so" to the method,
and that copy is passed by value. It does happen that the value passed is
a reference, but there is no way for the method to change the original
variable used as a parameter, and thus it is not being passed by reference.
Don't confuse references to objects with references to parameters. They
aren't the same.
> For the record I don't like the "swap" example that gets trotted out to
> explain that Java is not pass-by-reference (as an example,
> http://www.javaworld.com/javaworld/javaqa/2000-05/03-qa-0526-pass.html).
> It's disingenuous. If I write the same example using C++ with pointers to
> objects, I get the same results...surprise, surprise.
That's only if you pass those pointers by value. That is, you pass the
values themselves rather than a reference to the variables that reference
the values. And yes, in C++ just as passing by value prevents you from
changing the original variables, so too does passing by value in Java.
In fact, that's exactly why the "swap" example is so simple and
applicable. Passing a pointer to an object in C++ is just like passing a
reference in Java. In both cases, the reference to the object is passed
by value: a copy of the reference is passed, and thus the variable that
was used as the parameter is not changeable by the function being called.
So, if you "write the same example using C++ with pointers to objects",
you get the same results because in C++ you're passing the pointer to the
objects by value, not by reference.
Pete
Chris Smith
>> Ah, but the problems arise when people try things precisely like the
>> example that started this thread. That is, try to write:
>> val = "New String";
>
> The only reason this doesn't work as they think, is because assignment
> is always on the "pointer" and never on the whole Object.
Right, because the pointer (or null) is what val *is*. That is the
critical point here. The parameter is a reference, not an object. In
order to view this as pass-by-reference, you'd have to look at the
parameter itself as an object; a perspective that's generally in the
ballpark of what's going on, but is ultimately an inadequate model for
understanding the language.
> Given a C-style pointer, one can (in C) either change the pointer, or
> the pointed-to Object using assignment:
> int i=42,j=84,*p=&i; // p is a pointer to i *p = 43; // now "i"
> contains 43 (java has no pendant for that) p = &j; // "i" is not
> touched, but p points to j now.
Indeed, because p is the pointer, while *p is the object pointed to.
Therefore, when p occurs on the left of an assignment, the pointer is
assigned. When *p does, the object is assigned. It's worth noting now
that C, like Java, has no pass by reference semantics. It is another
language that is entirely pass by value.
> It isn't really necessary to resort to parameter passing to see the
> difference.
No, it's certainly not necessary. But one you've got down the kinds of
values that a variable may have (primitive or reference), describing
parameter passing incorrectly, in such a way as to imply that variables
contain objects, then muddies the waters again.
>> By the (fairly universal) very definition of pass by reference, one
>> would expect this to work.
>
> By the (at least as "very") definition of "reference" alone, one might
> expect different behaviour of Java already. No matter if it is passed or
> not. Java doesn't really have "references" the way C++ has.
I'm not sure what C++ has to do with this.
There really isn't a widely used definition of a reference. The word is
used differently by different languages, and it's best to just adopt the
definition from the language in question. C++ means one thing; Java
another; CAML yet another. On the other hand, pass-by-reference is a
concept with a well-understood definition. Namely: the lvalue of the
formal parameter is the same as the lvalue of the actual parameter.
> The confusion comes from talking about "references" in Java in the first
> place, not from how something is passed to methods.
I don't agree with this. It works perfectly well to talk about
references in Java, and acknowledge that they are passed by value.
> [ example of a mutable Object that get's passed down
> into a function and modified there
Actually, that's not what happened at all. The function modified global
state (a static field of the class). I'm afraid you missed the point of
the example. I would be shocked if you are willing to call it pass by
reference. And yet it's ultimately the same thing that's going on when
you modify object state via references passed as parameters.
> Btw., even in C++, which I think we agree does support both by-value and
> by-ref passing of objects, really passes on only "addresses by value"
> for that. Where is the difference? The difference is in the semantics
> of assignment.
You are confusing the implementation with the language semantics. When
you pass something by reference in C++, the lvalue of the formal
parameter is the same as the lvalue of the actual parameter. In other
words, the formal parameter is just another name for the same object. So
when you assign to the formal parameter, you are assigning to that
object. That is the only thing that C++ tells you, so it's the only
thing you know. Anything else is speculating about the implementation
details of the compiler.
If we want to engage in such speculation: one possible implementation
(the one likely used for calls between separately compiled modules) is
that the compiler translates this into pushing a memory address onto the
stack. Another implementation technique is to arrange the stack such
that in all calls to a function, the object passed by reference is at a
fixed offset from the end of the caller's stack frame and then accessing
it directly where it sits there. Yet another, useful for small objects
and primitives (which are objects in C++ parlance) in inlined functions,
is to arrange so that the object is allocated to a register rather than
memory in the calling procedure, and leaving that register allocated for
that purpose across the procedure call so that there is no memory address
at all.
So long as the implementation is faithful to the semantic model of what's
going on, it is acceptable. The language semantics don't say that a
memory address is passed. There is nothing in the C++ language
specification about inserting pointer dereference operators
automatically, or anything like that. The spec says that the formal
parameter name inside the function denotes the same object as the actual
parameter in the calling context. It's the poorer books on C++ that
insist on describing behavior in terms of implementation.
--
Chris Smith
Andreas Leitgeb
>> and "pass references (to objects) by value" are the same.
> How do you deal with null actual arguments? null is a fine value for a
> Java reference, but is not an object.
It's as if I got an empty jar after asking for "sugar".
I still will not ask for a "jar" just to avoid this "problem"
of not being able to lingually handle this situation.
Lew
Some people obstinately refuse to use the distinctions of the programming
environment in which they work. That's your privilege. To the general public
reading this newsgroup, know the actual distinctions of Java, and don't let
others' inaccurate renditions distort your understanding.
"Psss by reference" and "pass reference by value" are not the same thing, as
many have pointed out here. If you want to deliberately misspeak that's fine,
but it will confuse the conversation with more rigorous practitioners.
--
Lew
Roedy Green
quoted or indirectly quoted someone who said :
> The parameter is a reference, not an object.
In C++, you can copy entire objects or copy a reference to an object
with = or with parameter passing. In Java it is simpler. You can just
pass the reference. To copy an entire object, you must use the clone
method.
In C++, objects is RAM tend to be contiguous. In Java they are just a
collection of pointers to pieces separately stored. Only the
primitives live in the object itself.
The Java way eliminates the plethora of addressing and dereferencing
modes you have in C++. The drawback of java is, an array of complex
real/imaginary pairs in Java is scattered all over RAM, one object per
complex value, plus one to track the references to them. In C++ you
can store it all in one contiguous hunk much more compactly.
Roedy Green
>However, I don't think I mean "pass by reference" and "pass by value" as
>anything other than the intuitive meanings:
These terms have an established meaning in Java. They are somewhat
arbitrary, but they do work better than many alternatives. This was
all hashed out long ago in the days of Java 1.0.
I recall getting smacked down myself back then for not respecting the
established meanings.
Patricia Shanahan
I think the jar analogy breaks down badly here. I would not hand someone
an empty jar if they asked me to pass the jam, even if the jar were
suitable for jam, or even contained jam at some time in the past, and
might contain jam again in the future.
"Pass the jam." asks for the content, even if it has to be contained and
passed in a jar. "Pass an argument of type String." asks for a String
reference, and can in some cases be usefully satisfied by passing a null
reference to String.
The "pass the jam" analogy would work for languages that really do have
call-by-reference. The callee needs the caller's object. In practice, it
will be represented, under the hood, by a pointer, but there has to be a
real object, real jam in the jar.
Patricia
Andreas Leitgeb
> With objects, Java still does a). The parameter is a variable that
> references the object. It's not the object itself. And a copy of that
> reference the variable holds is passed. If Java did support
> pass-by-reference, and you passed an object reference "by reference", then
> reassigning the reference would not change the original object, but rather
> would change the variable that was pointing to (referencing) that object.
I dare the bold assumption, that all partitioners in this discussion do
know how java works.
We're only discussing human language here, not Java's features.
a) Does anyone disagree, that "pass an Object by reference" and
"pass the reference to an Object by value" refer to the same
technical feature?
b) Does anyone disagree that "pass a reference by reference" is an
entirely different feature that is not directly supported by
java, but can be effectively mimicked with arrays and/or Holder-
classes?
Would anyone care to point out any difference of the two concepts in
"a)" without mixing it up with the concept in "b)" ?
> In C#, you can additionally pass parameters by reference, including references.
This is also "pass ... by reference", but with C#'s meaning of references,
whereas Java's "pass Objects by reference" is based on java's "references".
Therefore "pass by reference" means something different depending on
the language context.
> If you insist on saying that passing a reference to an object is "passing
> by reference", then what does it mean to pass a reference by reference, as
> you can do in C# (and C++ for that matter)?
exactly that: "pass a reference by reference" :-)
Lew
> Peter Duniho <NpOeS...@nnowslpianmk.com> wrote:
>> With objects, Java still does a). The parameter is a variable that
>> references the object. It's not the object itself. And a copy of that
>> reference the variable holds is passed. If Java did support
>> pass-by-reference, and you passed an object reference "by reference", then
>> reassigning the reference would not change the original object, but rather
>> would change the variable that was pointing to (referencing) that object.
>
> I dare the bold assumption, that all partitioners in this discussion do
> know how java works.
>
> We're only discussing human language here, not Java's features.
Actually, it's the exact opposite - we are discussing Java's features, not the
non-technical use of the terms. Besides, "pass by value" and "pass by
reference" are technical terms, with specific meanings, and completely lack
colloquial meanings.
> a) Does anyone disagree, that "pass an Object by reference" and
> "pass the reference to an Object by value" refer to the same
> technical feature?
Yes, everyone here who is actually familiar with the technical terms.
> b) Does anyone disagree that "pass a reference by reference" is an
> entirely different feature that is not directly supported by
> java, but can be effectively mimicked with arrays and/or Holder-
> classes?
> Would anyone care to point out any difference of the two concepts in
> "a)" without mixing it up with the concept in "b)" ?
Many have already. Review the thread.
> This is also "pass ... by reference", but with C#'s meaning of references,
> whereas Java's "pass Objects by reference" is based on java's "references".
> Therefore "pass by reference" means something different depending on
> the language context.
Yes, so refusing to use the meaning that is specific in that context is
confusing and foolish.
--
Lew
Peter Duniho
<a...@gamma.logic.tuwien.ac.at> wrote:
> I dare the bold assumption, that all partitioners in this discussion do
> know how java works.
I'd say that's a bold assumption indeed. Part of the problem is that
people who are unwilling to be precise in how they use the terms either do
not themselves comprehend how Java works, or they make it more difficult
for others new to Java to comprehend how Java works.
Either way, being imprecise is a problem.
> We're only discussing human language here, not Java's features.
We're discussing a very narrow use of human language, in which we discuss
Java's features. In every day conversation you can get away with being
vague much of the time. In a technical, professional setting it is of
paramount importance to use precise, accepted terminology. Equivocating
on the terminology is pointless...all you do is interfere with your
ability to communicate with other professionals.
> a) Does anyone disagree, that "pass an Object by reference" and
> "pass the reference to an Object by value" refer to the same
> technical feature?
I do. Saying "pass by reference" implies a language feature. Java has no
way to pass an object by reference. Objects cannot be parameters at all,
so how could they be passed by reference? Variables referencing objects
can be parameters, and in Java you can only pass such references to an
object by value.
Those who would treat the two phrases as equivalent are not being suitably
precise enough to unambiguously describe code. It's fine if you want to
use that sort of language at a cocktail party. But when you're trying to
get actual work done, it's not appropriate.
> [...]
>> In C#, you can additionally pass parameters by reference, including
>> references.
>
> This is also "pass ... by reference", but with C#'s meaning of
> references,
> whereas Java's "pass Objects by reference" is based on java's
> "references".
C#'s meaning of references is exactly the same a Java's meaning of
references.
> Therefore "pass by reference" means something different depending on
> the language context.
Not in this case, it doesn't. The two languages use the term "reference"
identically: it's an implementation-dependent value that refers to an
instance of an object.
Neither language can pass an object by reference, though they can both
pass references to objects by value. Additionally, C# can pass any
parameter (including references to objects) by reference.
>> If you insist on saying that passing a reference to an object is
>> "passing
>> by reference", then what does it mean to pass a reference by reference,
>> as
>> you can do in C# (and C++ for that matter)?
>
> exactly that: "pass a reference by reference" :-)
Nope. You've already used "by reference" to describe a particular syntax
of parameter passing. You need a new term to describe the use of the
"ref" or "out" keyword. Otherwise, your semantics of describing the
language is incomplete.
This is my point. Your insistence on describing two completely different
mechanisms identically fails to provide unambiguous langauge with which to
describe the language.
Again, this is fine if you're just chatting with your friends where no one
really cares what anyone else is saying anyway. But if you want to get
any real work done, you need to use your language more carefully and more
precisely than that.
Pete
Chris Smith
> a) Does anyone disagree, that "pass an Object by reference" and "pass
> the reference to an Object by value" refer to the same technical
> feature?
Yes, we basically all disagree. This is based on the simple fact that
they are different things. You can't do one of them in Java, whereas you
can do the other.
In C++, a language where you can do both, the difference is in whether
you specify the parameter as `Class &v` or `Class *v`. The first passes
an object by reference, while the second passes a pointer (basically a
reference in Java terminology) by value.
> b) Does anyone disagree that "pass a reference by reference" is an
> entirely different feature that is not directly supported by java, but
> can be effectively mimicked with arrays and/or Holder- classes?
This is a special case of the fact that "pass X by reference" is always
not directly provided by Java, for all values of X. You've plugged "a
reference" for X there, so you have a true statement. It would remain
true no matter what else you substitute for X.
> Would anyone care to point out any difference of the two concepts in
> "a)" without mixing it up with the concept in "b)" ?
I've been trying. If you don't see what I'm saying, feel free to ask,
but please point out what you disagree with or don't understand.
>> In C#, you can additionally pass parameters by reference, including
>> references.
>
> This is also "pass ... by reference", but with C#'s meaning of
> references, whereas Java's "pass Objects by reference" is based on
> java's "references". Therefore "pass by reference" means something
> different depending on the language context.
Actually, this may be the point of confusion. Pass by reference is a
concept that has a particular meaning, independent of any other use of
the word "reference" in a language. In particular, pass by reference has
nothing to do with references in Java, or C#, or Ocaml, or most other
languages that call something a reference. The two concepts are related
in C++ specifically because the language committee chose to define
references as a generalization of the concept of pass by reference; 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.
--
Chris Smith
Andreas Leitgeb
> "Pass by reference" and "pass reference by value" are not the same thing, as
Many respectable participants of this group have indeed pointed
it out, but they have still kept back any *convincing* arguments
they might have to support their positions.
> If you want to deliberately misspeak that's fine,
Misspeaking is not my intention.
Claiming that "pass by reference" is a well-defined term
across all languages, while "reference" itself is not,
just fails to convince me.
Andreas Leitgeb
> passed in a jar. "Pass an argument of type String." asks for a String
> reference, and can in some cases be usefully satisfied by passing a null
> reference to String.
I never questioned the "reference by value" phrase on technical level.
One level up, however, passing a null-ref may be forbidden, and cause a
NullpointerException to be thrown. At this level, we aren't interested
in empty jars ... ahem... "null", so at that level, talking about
reference-passing is just as common as "passing Objects around".
One level up, java looks quite different.
Lew
>> "Pass by reference" and "pass reference by value" are not the same thing, as
>> many have pointed out here.
Andreas Leitgeb wrote:
> Many respectable participants of this group have indeed pointed
> it out, but they have still kept back any *convincing* arguments
> they might have to support their positions.
You mean, other than citing the very definitions of the terms? It's a matter
of definition, not convincing. You are being Humpty Dumpty in /Through the
Looking Glass/ -
> [Humpty Dumpty said,] '...There's glory for you!'
>
> 'I don't know what you mean by "glory,"' Alice said.
>
> Humpty Dumpty smiled contemptuously. 'Of course you don't--
> till I tell you. I meant "there's a nice knock-down argument for
> you!"'
>
> 'But "glory" doesn't mean "a nice knock-down argument,"' Alice
> objected.
>
> 'When _I_ use a word,' Humpty Dumpty said in rather a scornful
> tone, 'it means just what I choose it to mean--neither more nor
> less.'
Lew said,
>> If you want to deliberately misspeak that's fine,
Andreas Leitgeb wrote:
> Misspeaking is not my intention.
Sure it is. You keep presenting arguments for why you should misspeak, and
announcing that you will continue do so in the face of correction. If that
isn't intentional, then nothing is.
> Claiming that "pass by reference" is a well-defined term
> across all languages, while "reference" itself is not,
> just fails to convince me.
OK. Who did that? In this thread, people have pointed out that there is a
specific technical meaning to the term, illustrated with examples, which you
continue to reject. No one has made the claim that it applies across all
languages, simply pointed out the languages for which the term does apply.
Obviously nothing I say will make a dent in your obstinacy.
--
Lew
Lew
> One level up, however, passing a null-ref may be forbidden, and cause a
Passing a null reference does not cause a NullPointerException. Dereferencing
a null reference does that.
> in empty jars ... ahem... "null", so at that level, talking about
"Level"? What are you on about?
> reference-passing is just as common as "passing Objects around".
"Passing Objects around" doesn't happen in Java. At any "level", there is
specific technical terminology for what happens in parameter passing. Whether
null is a valid value for a given method is orthogonal to that terminology, in
face, unrelated to it.
> One level up, java [sic] looks quite different.
There are no "levels" here. You bring up a question of value validity, for
which a method would have an explicit test, that has nothing whatsoever to do
with whether parameters are passed by value or reference, and call it a
"level", whatever the heck that's supposed to mean. Nothing in that argument
has any bearing on the correctness of referring to "passing objects" as Java
method parameters, which doesn't ever happen, nor on the matter of pass by
reference versus pass by value. At all.
--
Lew
Patricia Shanahan
> Peter Duniho <NpOeS...@nnowslpianmk.com> wrote:
>> With objects, Java still does a). The parameter is a variable that
>> references the object. It's not the object itself. And a copy of that
>> reference the variable holds is passed. If Java did support
>> pass-by-reference, and you passed an object reference "by reference", then
>> reassigning the reference would not change the original object, but rather
>> would change the variable that was pointing to (referencing) that object.
>
> I dare the bold assumption, that all partitioners in this discussion do
> know how java works.
>
> We're only discussing human language here, not Java's features.
Somewhat agree. The purpose of human language, in this situation, is to
enable thought about Java's features, and the ability to communicate
understanding of those features from one person to another.
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, in the sense of changing what object it
references. As far as I can tell, talking about passing a reference by
value, and about variables and expressions being references not objects,
does not lead to any false expectations.
What do you think is the main objective in selecting terminology to
describe Java parameter passing?
Patricia
Andreas Leitgeb
> Yes, so refusing to use the meaning that is specific in that context is
> confusing and foolish.
Says the one, who insists on the language-neutral meaning of
"pass by reference", re-minted on java's references, which
aren't really "references" in the context of where "pass by
reference" was coined.
Patricia Shanahan
> Andreas Leitgeb wrote:
>> One level up, however, passing a null-ref may be forbidden, and cause
>> a NullpointerException [sic] to be thrown. At this level, we aren't
>> interested
>
> Passing a null reference does not cause a NullPointerException.
> Dereferencing a null reference does that.
And a null reference behaves exactly the same way regardless of how one
obtained the null reference.
Dereferencing a formal parameter that represents a null reference actual
parameter is equivalent to dereferencing a local variable or field whose
value is currently null. That is part of the power of the "pass a
reference by value" model.
Patricia
Lew
Wha...?
Is there a point in there?
Where did I suggest a "language-neutral meaning" of "pass by reference"? All
my comments on this thread have been specific to the Java meaning. I've even
made the explicit statement, "we are discussing Java's features" and referrred
to "the actual distinctions of Java" and "the official word in Java"
specifically. What are you on about?
--
Lew
rmoldsk...@online.no
> One level up, java looks quite different.
If you only look on Java in isolation there is no point in discussing "pass
by value"/"pass by reference." Java only does one and the "Java idiom" of
(Java) reference types means that the programmer doesn't have to think about
it.
It's only when Java is discussed in general as a programming language or
when it is compared to another programming language that it makes sense to
talk about "pass by value"/"pass by reference" in relation to Java. It is
not a Java term. It's a _programming language_ term, describing how
arguments are passed to subprograms. It's a pretty low level term -- it has
no meaning "one level up."
Yes, Java does automatic dereferencing and uses _reference types_ as the
arguments to its subprograms (along with fundamental types, of course.) This
simplifies things for the programmer, but it does not mean that Java has
pass by reference.
The difference is seen when you consider C++. In C++ you can have a variable
with a typed pointer (equivalent to a reference type in java), which points
to an object on the heap. You can pass this pointer to a subprogram either
by value or by reference. _In both cases_ will you be able to access and
modify the object pointed to -- but only in the latter case will you be able
to modify the contents of the original variable and set it to point to some
other object.
Merely being able to modify objects in a subprogram does not mean you have
pass by reference. You only have that if the following program pirnts out
"By Reference":
public class Demo {
public void notByReference( String message ) {
message = "By Reference";
}
public static void main( String[] args ) {
String message = "By Value";
notByReference( message );
System.out.println( message );
}
}
--
Leif Roar Moldskred
Got Sfik?
Andreas Leitgeb
> Those who would treat the two phrases as equivalent are not being suitably
> precise enough to unambiguously describe code. It's fine if you want to
> use that sort of language at a cocktail party. But when you're trying to
> get actual work done, it's not appropriate.
I pick my (human) language depending on who I talk with.
If the topic is, how parameter passing actually works, then I admit
that "passing references by value" is the more accurate description.
If I were to describe a method like: public void foo(String x) {...}
I'd probably start with "it takes a String and returns nothing".
Would you say: "It takes a reference to a String" ? If so, then
ten points for exactness, and minus hundred points for a dry mouth
from over-repeating the word "reference" :-)
There are times for exact language, and times where focus is on
other aspects. That's the other level I've kept mentioning.
> But if you want to get any real work done, you need to use your
> language more carefully and more precisely than that.
If I want the work done, I assume that my colleagues know Java,
and know how Objects are handled and their pointers passed around,
so we simplify our language, strip it of unproductive cruft, and
talk about passing Objects around, rather than wasting breath for
saying "reference" twenty times per minute.
Lew
>> One level up, java [sic] looks quite different.
rmoldsk...@online.no wrote:
> If you only look on Java in isolation there is no point in discussing "pass
> by value"/"pass by reference." Java only does one and the "Java idiom" of
> (Java) reference types means that the programmer doesn't have to think about
> it.
>
> It's only when Java is discussed in general as a programming language or
> when it is compared to another programming language that it makes sense to
> talk about "pass by value"/"pass by reference" in relation to Java. It is
> not a Java term. It's a _programming language_ term, describing how
> arguments are passed to subprograms. It's a pretty low level term -- it has
> no meaning "one level up."
Jon Skeet has written a thorough explanation of this very matter at
<http://www.yoda.arachsys.com/java/passing.html>, including a rather formal
breakdown of the distinctions.
Quotes from the site:
"Everything in Java is passed by value. Objects, however, are never passed /at
all/." (Emph. orig.)
"The reason there is so much confusion is people tend to blur the distinction
between an object reference variable and an object instance."
"There are good reasons that Java excluded the idea of pass-by-reference from
its language design, and when writing Java applications it's best to do as
Java does."
"... pass by reference allows the variable to be changed, and the changed
value can be seen in client code."
"This is the real reason why pass by reference is used in many cases - it
allows a method to effectively have many return values. Java doesn't allow
multiple 'real' return values, and it doesn't allow pass by reference
semantics which would be used in other single-return-value languages."
--
Lew
Andreas Leitgeb
> Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at> wrote:
>> One level up, java looks quite different.
> If you only look on Java in isolation there is no point in discussing "pass
> by value"/"pass by reference." Java only does one and the "Java idiom" of
> (Java) reference types means that the programmer doesn't have to think about
> it.
You're right. In that case I really speak of "passing objects" omitting
any "by ...". This is also frowned upon by others, but is a lingual
shortcut for what really happens, namely "passing a reference to the object
by value".
> It's only when Java is discussed in general as a programming language or
> when it is compared to another programming language that it makes sense to
> talk about "pass by value"/"pass by reference" in relation to Java. It is
> not a Java term. It's a _programming language_ term, describing how
> arguments are passed to subprograms. It's a pretty low level term -- it has
> no meaning "one level up."
I still follow you...
> Yes, Java does automatic dereferencing and uses _reference types_ as the
> arguments to its subprograms (along with fundamental types, of course.)
Here, I'm lagging somewhat behind. Where does java "automatic deref"?
Do you mean because method names are appended after a ".", and not after
a "->" as in C with pointers?
It's my point, that java does not auto-deref, but that java's "." is
just C's "->", so the deref is really explicit, but hidden behind a
concise syntax.
> Merely being able to modify objects in a subprogram does not mean you have
> pass by reference.
Ok, I think you hit the nail on the head. My position is, that C++'s
"call by reference" is actually *very* similar to Java's way of reference
passing: there are only two differences:
- C++ can also do "by-ref" with primitives, Java can not.
- C++'s assignment to a reference(aka.: "name-alias") is always a
modification on the referenced Object, never on the reference.
Even in C++, I'm "merely able to modify objects in a subprogram", but in C++
it's still called "pass by reference".
Back to Java:
...
myMethod(final Object foo) {...}
...
Whatever legal things I do with foo inside myMethod will be reflected
outside. Is *that* "call by ref" then? "foo" inside myMethod is now
just as (un-)retargettable as a reference in C++ is.
Peter Duniho
<a...@gamma.logic.tuwien.ac.at> 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.
Patricia Shanahan
> Peter Duniho <NpOeS...@nnowslpianmk.com> wrote:
>> Those who would treat the two phrases as equivalent are not being suitably
>> precise enough to unambiguously describe code. It's fine if you want to
>> use that sort of language at a cocktail party. But when you're trying to
>> get actual work done, it's not appropriate.
>
> I pick my (human) language depending on who I talk with.
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.
Patricia
Andreas Leitgeb
> 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".
Perhaps I should have used "by use of" rather than just "by", to
avoid collision with that technical definition.
> 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.
Patricia Shanahan
> Patricia Shanahan <pa...@acm.org> 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
Chris Smith
> Perhaps I should have used "by use of" rather than just "by", to avoid
> collision with that technical definition.
Two comments:
1. In general usage, it's entirely normal to talk about passing an object
to a method. If more precision is required, then someone will initiate
that level of precision by making a more explicit statement involving
references.
2. This thread, in particular, is *about* pass by reference, so the
discussion here is quite precise about exactly what is happening. Don't
think that's the norm. Of course, if you use the phrase "pass by
reference" or something that sounds nearly like it, there will probably
be corrections since that phrase has a specific meaning. But in general,
there is no language police around to correct you every time you talking
about passing a Date object to some method. The more precise language
may be brought up only if someone feels there is confusion about what's
going on at a lower level.
> 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.
Hmm. Presumably, everyone here has at least some desire to become an
experienced programmer, if they aren't already.
--
Chris Smith
Wayne
> Patricia Shanahan <pa...@acm.org> 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.
>
>
> »Some people will say incorrectly that objects are passed
> "by reference".
>
> 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. If the function
> modifies its parameter, the value in the calling code will
> be changed because the argument and parameter use the same
> slot in memory.
>
> The Java programming language does not pass objects by
> reference; it passes object references by value. Because
> two copies of the same reference refer to the same actual
> object, changes made through one reference variable are
> visible through the other. There is exactly one parameter
> passing mode-pass by value-and that helps keep things simple.«
>
> James Gosling, The Java Programming Language, 3rd Edition, quoted from
>
> http://forum.java.sun.com/thread.jspa?threadID=591738&messageID=3087303
>
> »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)
>
> »call 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 »parameters« is
> being called »arguments« in Java.
>
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. I don't find
it mentally taxing to think of passing references by copy; that's
how I used to envision passing pointers in C.
Does anyone remember Fortran's pass by copy-back (or copy-reference)?
Or older, Algol W (I think) that used pass by name?
Or newer, K&R C's pass by value...sometimes, depending on the size
of the object?
I'm personally quite happy with Java's pass by copy/value only!
-Wayne
Lew
> Back to Java:
> ...
> myMethod(final Object foo) {...}
> ...
> Whatever legal things I do with foo inside myMethod will be reflected
> outside. Is *that* "call by ref" then?
No, it is not call by reference.
--
Lew
Chris Smith
In particular, the call by reference (with objects as parameters) mental
model still doesn't explain what happens when null is passed for the
parameter. So instead of one simple and semantically correct semantic
model, you have to remember to think of it as call by reference, but with
some special cases for null, and only if the parameter is final, except
on the third Sunday after a blue moon...
--
Chris Smith
Lasse Reichstein Nielsen
> We're only discussing human language here, not Java's features.
>
> a) Does anyone disagree, that "pass an Object by reference" and
> "pass the reference to an Object by value" refer to the same
> technical feature?
Yes!
"pass ... by reference" means passing an l-value. It allows
changing the value of *a variable* that is passed by reference.
"pass ... by value" means passing an r-value.
In either case, if the value of the passed variable/the passed value
is a pointer or (Java) reference, you can change the data that it
points to/object that it references. That is separate from whether
you can change the variable itself.
> b) Does anyone disagree that "pass a reference by reference" is an
> entirely different feature that is not directly supported by
> java, but can be effectively mimicked with arrays and/or Holder-
> classes?
Reasonable.
>
> Would anyone care to point out any difference of the two concepts in
> "a)" without mixing it up with the concept in "b)" ?
Done?
>> In C#, you can additionally pass parameters by reference, including references.
>
> This is also "pass ... by reference", but with C#'s meaning of references,
> whereas Java's "pass Objects by reference" is based on java's "references".
> Therefore "pass by reference" means something different depending on
> the language context.
Disagree. "Pass by reference" (or really "call by reference") is a
technical term with a *long* history (e.g., "Call-by-name,
call-by-reference and the Lambda calculus", Reynolds 72). It has not
been given a different meaning in a Java context. Or, if it has, the
term is now ambiguous and should be avoided.
>> If you insist on saying that passing a reference to an object is "passing
>> by reference", then what does it mean to pass a reference by reference, as
>> you can do in C# (and C++ for that matter)?
>
> exactly that: "pass a reference by reference" :-)
If "passing a reference" is the same as "passing an object by
reference", then "passing a reference by reference" would be the same
as "passing an object by reference by reference"? I think not :)
/L
--
Lasse Reichstein Nielsen - l...@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
rmoldsk...@online.no
> Here, I'm lagging somewhat behind. Where does java "automatic deref"?
> Do you mean because method names are appended after a ".", and not after
> a "->" as in C with pointers?
> It's my point, that java does not auto-deref, but that java's "." is
> just C's "->", so the deref is really explicit, but hidden behind a
> concise syntax.
Auto-boxing and string concatenation, instanceof, array indexing.
> 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?
>
> Back to Java:
> ...
> myMethod(final Object foo) {...}
> ...
> Whatever legal things I do with foo inside myMethod will be reflected
> outside. Is *that* "call by ref" then? "foo" inside myMethod is now
> just as (un-)retargettable as a reference in C++ is.
No, "pass by reference" doesn't _exist_ in Java. Declaring a method
parameter as final only limits what the subprogram can do with it, it
doesn't change how it's passed into the program.
Consider the following
public class Foo {
public static Widget assignedWidget = new Widget( 1 );
public void doDelayedBar( final Widget w ) {
Thread.sleep( 10000 );
w.bar( );
}
}
Now imagine that we somewhere in our program call doBar(Foo.assignedWidget);
and while that method is waiting in Thread.sleep( ) another thread sets
Foo.assignedWidget = new Widget( 2 );
Which instance of Widget will doDelayedBar( ) call bar( ) on? The first, of
course. But if Java had used call by reference it would have been the
second, because the change to assignedWidget would have been visible inside
of doDelayedBar( ).
Andreas Leitgeb
> 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).
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"?
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.
Andreas Leitgeb
> 2. This thread, in particular, is *about* pass by reference, so the
> discussion here is quite precise about exactly what is happening.
You're right here. I missed that drift.
> there is no language police around to correct you every time you talking
> about passing a Date object to some method. The more precise language
> may be brought up only if someone feels there is confusion about what's
> going on at a lower level.
100% agree. I failed to notice, that the thread was nearer to the
technical than to the informal "level".
I'll reread the article to which I first followedupto in this Thread, and
see if I see it differently now, on rereading.
> Hmm. Presumably, everyone here has at least some desire to become an
> experienced programmer, if they aren't already.
"desires to become".equals("is") == false :-)
Lew
>> 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.
Andreas Leitgeb wrote:
> 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 Java defines "reference" in a particular way, but not "call by
reference", which is an industry standard term, as I have learned here. The
two terms do not depend on each other for their meaning, in the way you wish
to imply.
> 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.
We aren't discussing "natural" language, we are discussing technical argot.
Enough people have expressed the dangers inherit in deliberately
misinterpreting "pass references by value" to mean "pass objects by
reference". Those with the wisdom to appreciate the reasoning will make the
distinction.
--
Lew
Lew
>> Hmm. Presumably, everyone here has at least some desire to become an
>> experienced programmer, if they aren't already.
Andreas Leitgeb wrote:
> "desires to become".equals("is") == false :-)
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". Otherwise we do a huge disservice to those who wish to become
(good) experienced programmers.
--
Lew
Patricia Shanahan
> Patricia Shanahan <pa...@acm.org> 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
Arved Sandstrom
news:47f8654d$0$4409$c3e...@news.astraweb.com...
> Andreas Leitgeb wrote:
[ SNIP ]
>>
>> By the (at least as "very") definition of "reference" alone, one might
>> expect different behaviour of Java already. No matter if it is passed or
>> not. Java doesn't really have "references" the way C++ has.
>
> I'm not sure what C++ has to do with this.
>
> There really isn't a widely used definition of a reference. The word is
> used differently by different languages, and it's best to just adopt the
> definition from the language in question. C++ means one thing; Java
> another; CAML yet another. On the other hand, pass-by-reference is a
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> 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. I spent the past few days doing some fairly intense research
(Googling) on pass by reference, pass by value (also keywords "call by ...",
"pointer", "evaluation strategy", etc etc) and so forth. I tried to
categorize sources as summary and explanatory: "summary" sources had a quick
definition of a term used in this thread, and "explanatory" sources actually
had some discussion of the topics. Naturally I also applied some measure of
quality control, without trying to apply a personal bias based on my own
perspective (which has already been expressed).
(Note: I'll use PBV and PBR to abbreviate "pass by value" and "pass by
reference".)
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". Like it or not, while people do understand PBV to
mean copying the value of the actual argument into the formal parameter
variable, they (myself included) also make a difference between that actual
argument being the thing of interest (a primitive or object) or being a
reference to the thing of interest.
I'd like to think that most folks, including everyone participating in this
thread, grasps the difference between passing a pointer by value and passing
a reference...the swap() function example, so to speak. In one you can
actually change the value of the thing passed as it visible in the caller,
and in the other you cannot. Yes, you can use pointers to modify the value
of the thing pointed at, in the calling code, but that's still not modifying
the actual parameter passed (the pointer) as it exists in the calling code.
However, lots of people (again, myself included) do describe "passing a
pointer by value" as PBR, insofar as being able to modify the pointed-to
thing is very often described as PBR. And the reason this terminology is
common because when passing a pointer by value you do in fact have a
reference to the object. I'm trying not to be argumentative here, I'm just
pointing out (pun not intended) that there are at least two different usages
of the word "reference" here, one somewhat less technically precise than the
other, but both are (arguably) valid. It depends on the context.
I myself am perfectly happy to use the more precise language to keep Java
people happy - it's no sweat off my back. But equally well I'm not going to
correct a C programmer who says "pass by reference" (when it's "pass pointer
by value") when he clearly knows what it is he or she is doing.
AHS
Andreas Leitgeb
focus has moved from insisting to use "by ref" in java-context
to understanding the technical difference in detail.
Chris Smith <cds...@twu.net> 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.
Arved Sandstrom
news:op.t87on...@petes-computer.local...
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
Andreas Leitgeb
> 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"...
Arved Sandstrom
news:call-2008...@ram.dialup.fu-berlin.de...
> Patricia Shanahan <pa...@acm.org> 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.
>
>
> »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)
>
> »call 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 »parameters« is
> being called »arguments« 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
rmoldsk...@online.no
> 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.
As C++ supports both pass by reference and pass by value, that's hardly
surprising. Even if we limit ourselves to pass by reference, though, we will
always be able mimick the behaviour of pass by value by making a local copy
of whatever is referenced.
It's like with diesel and gasoline engines: the difference isn't in what you
can _do_ with them, but in how they _work_. If you're not a language
implementer all you usually just have to make sure of is that you put diesel
on the diesel engine and gasoloine on the gasoline engine.
--
See my previous post for .sig
Andreas Leitgeb
> 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.
Arved Sandstrom
news:ftbmf3$1bqv$1...@ihnp4.ucsd.edu...
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