call by reference

[Roedy Green]

that was true in 1970, but it may have evolved since then.

I recall accidentally redefining the integer 1 in a subroutine when I
had passed the literal 1 as a parameter.

back then this Java equivalent was a no no:

void amethod( int i );
{
i++;
}

amethod( 1 );

you would actually change the constant 1 to be 2 for everyone.

--
Bush crime family lost/embezzled $3 trillion from Pentagon.
Complicit Bush-friendly media keeps mum. Rumsfeld confesses on video.
http://www.infowars.com/articles/us/mckinney_grills_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes

 

[George Cherry]

that was true in 1970, but it may have evolved since then.

I recall accidentally redefining the integer 1 in a subroutine when I
had passed the literal 1 as a parameter.

back then this Java equivalent was a no no:

void amethod( int i );
{
i++;
}

amethod( 1 );

you would actually change the constant 1 to be 2 for everyone.

That would be an "in out" parameter in Ada, I believe.
Parameters in Ada were "in", "out", or "in out". "In" mode
parameters copied function arguments "in" the formal
parameters; changes to the formal parameters were
not copied back out. Out mode parameters did not
copy arguments in the formal parameters; changes
to the in formal parameters were copied back out.

I thought this was a good system, and should have been
adopted by Java.

George W. Cherry

 

[Mike Schilling]

that was true in 1970, but it may have evolved since then.

No, it was never true. The classic IBM Fortran IV compilers used copy-in
copy-out.

 

[Dale King]

That would be an "in out" parameter in Ada, I believe.
Parameters in Ada were "in", "out", or "in out". "In" mode
parameters copied function arguments "in" the formal
parameters; changes to the formal parameters were
not copied back out. Out mode parameters did not
copy arguments in the formal parameters; changes
to the in formal parameters were copied back out.

I thought this was a good system, and should have been
adopted by Java.

I for one am glad that they did not. I think there is inherent evil in a
system where you don't control whether someone else can modify your data.

Consider a simple call foo( a ) in C++? Does a get modified? You have no
way of knowing. Even if foo doesn't use references today someone else
could modify foo down the line and make it do so without modifying the
code that owns a. With Java's model (assuming you are taking normal
precautions and encapsulation) only the code of the class has control of
its own data.

But of course I don't always practice what I preach. I code in C++ for a
living and sometimes use pass by non-const reference, but it is rare and
usually has to do with avoiding exceptions because I am working in
embedded programming and exceptions are too expensive (on one compiler
it doubles the size of the executable) so I have to use return values
for errors.

 

[George Cherry]

I for one am glad that they did not. I think there is inherent evil in a
system where you don't control whether someone else can modify your data.

If you don't want a called procedure to affect your actual parameter
then don't call a procedure which has an "in-out" or "out" mode parameter.
But, of course, you couldn't call a lot of procedures then because many
procedures return their results by "in-out" or "out" mode parameters.
Something you ought to like is that the mode of the parameter ("in", "out",
or "in out") is part of the procedure's contract, and tells you clearly
whether
the procedure can "modify your data" (i.e., your actual parameters).

Consider a simple call foo( a ) in C++?

No. : o )

George W. Cherry

 

[Dale King]

If you don't want a called procedure to affect your actual parameter
then don't call a procedure which has an "in-out" or "out" mode parameter.
But, of course, you couldn't call a lot of procedures then because many
procedures return their results by "in-out" or "out" mode parameters.
Something you ought to like is that the mode of the parameter ("in", "out",
or "in out") is part of the procedure's contract, and tells you clearly
whether
the procedure can "modify your data" (i.e., your actual parameters).

No it tells you only that as currently written the procedure won't
modify your data. It can be changed by changing the procedure without
your code knowing the difference.

The advantage of the Java model is that there is never any doubt. The
procedure cannot change a value in your class' data simply because you
passed that value to the procedure.

With pass by reference the called procedure decides whether it can
modify your data. Without call by reference it does not have that power.

But of course you decided to actually ignore my example where I actually
discussed that. I only mentioned C++ as an example of a language that
has call by reference. Since you seem to prefer Ada, I'll reword the
paragraph that you ignored to apply to Ada:

Consider a simple call foo( a ) in Ada? Does a get modified? You have no
way of knowing. Even if foo doesn't use out parameters today someone
else could modify foo down the line and make it do so without modifying
the code that owns a. With Java's model (assuming you are taking normal
precautions and encapsulation) only the code of the class has control of
its own data.

 

[AndyRB]

I for one am glad that they did not. I think there is inherent evil in a

system where you don't control whether someone else can modify your data.

Consider a simple call foo( a ) in C++? Does a get modified? You have no
way of knowing.

Well I suppose you could do this:
SomeObj a;
const SomeObj &b = a;
foo(b);
Now the above will only compile if foo is pass by value or pass by
const reference.

Even if foo doesn't use references today someone else
could modify foo down the line and make it do so without modifying the
code that owns a. With Java's model (assuming you are taking normal
precautions and encapsulation) only the code of the class has control of
its own data.

My question is how is this different to the c++ situation? With proper
encapsution foo should only be modifable using the public member
functions in c++, so is this not the same as in Java?

Imagine you have something like the following in Java:
SomeObj a = new SomeObj;
foo(a);
I know that foo will not modify my reference a as it will be passed by
value, but my question is how do I know that it will not modify the
underlying SomeObj refered to by a?

Cheers,

Andy.

 

[Dale King]

Well I suppose you could do this:
SomeObj a;
const SomeObj &b = a;
foo(b);
Now the above will only compile if foo is pass by value or pass by
const reference.

That sure doesn't make me long for having out parameters. ;-)

My question is how is this different to the c++ situation? With proper
encapsution foo should only be modifable using the public member
functions in c++, so is this not the same as in Java?

Imagine you have something like the following in Java:
SomeObj a = new SomeObj;
foo(a);
I know that foo will not modify my reference a as it will be passed by
value, but my question is how do I know that it will not modify the
underlying SomeObj refered to by a?

You don't know that it won't call methods on SomeObj. In fact you expect
it otherwise why would you have passed it? But knowing that it can't
replace SomeObj with something else is quite a difference.

 

[AndyRB]

Imagine you have something like the following in Java:

You don't know that it won't call methods on SomeObj. In fact you expect
it otherwise why would you have passed it?

But some methods will simply access the object and others will modify
the object. I thought your issue with reference semantics was, if I
understood correctly, that from the function call you cannot tell
whether the object will be modified or not and, in particular, one day
it may not modify the object but the next that may change. On one day
foo may only be accessing the object, but the next it may be using
modifying methods. Would I be right in thinking that actually your
issue is when reference semantics are available to unencapsulated
types, like primatives and other POD types?

But knowing that it can't
replace SomeObj with something else is quite a difference.

When you say "replace SomeObj with something else", I take it in c++
terms you mean call the overloaded assignment operator for SomeObj? In
which case this is still modifying the object by calling a method on
SomeObj (assuming that operator has not been declared private).

Thinking about it, I guess the big difference is where c++ allows this
behaviour for all types including primitives, whereas in Java it is
restriced to objects and therefore, as you say, only available via the
objects methods.

Andy.