Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > call by reference

Reply
Thread Tools

call by reference

 
 
Roedy Green
Guest
Posts: n/a
 
      07-23-2005
On Wed, 20 Jul 2005 00:50:07 -0500, "John C. Bollinger"
<(E-Mail Removed)> wrote or quoted :

>
>> Checking the source again it says "FORTRAN only has reference mode;


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/...s_rumsfeld.htm

Canadian Mind Products, Roedy Green.
See http://mindprod.com/iraq.html photos of Bush's war crimes
 
Reply With Quote
 
 
 
 
George Cherry
Guest
Posts: n/a
 
      07-23-2005

"Roedy Green" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> On Wed, 20 Jul 2005 00:50:07 -0500, "John C. Bollinger"
> <(E-Mail Removed)> wrote or quoted :
>
>>
>>> Checking the source again it says "FORTRAN only has reference mode;

>
> 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



 
Reply With Quote
 
 
 
 
Mike Schilling
Guest
Posts: n/a
 
      07-23-2005

"Roedy Green" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> On Wed, 20 Jul 2005 00:50:07 -0500, "John C. Bollinger"
> <(E-Mail Removed)> wrote or quoted :
>
>>
>>> Checking the source again it says "FORTRAN only has reference mode;

>
> 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.


 
Reply With Quote
 
Dale King
Guest
Posts: n/a
 
      07-24-2005
George Cherry wrote:
> "Roedy Green" <(E-Mail Removed)> wrote in message
> news(E-Mail Removed)...
>
>>On Wed, 20 Jul 2005 00:50:07 -0500, "John C. Bollinger"
>><(E-Mail Removed)> wrote or quoted :
>>
>>
>>>>Checking the source again it says "FORTRAN only has reference mode;

>>
>>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.


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.

--
Dale King
 
Reply With Quote
 
George Cherry
Guest
Posts: n/a
 
      07-24-2005

"Dale King" <(E-Mail Removed)> wrote in message
news:VJCEe.200639$xm3.155339@attbi_s21...
> George Cherry wrote:
>> "Roedy Green" <(E-Mail Removed)> wrote in message
>> news(E-Mail Removed)...
>>
>>>On Wed, 20 Jul 2005 00:50:07 -0500, "John C. Bollinger"
>>><(E-Mail Removed)> wrote or quoted :
>>>
>>>
>>>>>Checking the source again it says "FORTRAN only has reference mode;
>>>
>>>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.

>
> 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

> 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.
>
> --
> Dale King



 
Reply With Quote
 
Dale King
Guest
Posts: n/a
 
      07-24-2005
George Cherry wrote:
> "Dale King" <(E-Mail Removed)> wrote in message
> news:VJCEe.200639$xm3.155339@attbi_s21...
>
>>George Cherry wrote:
>>
>>>"Roedy Green" <(E-Mail Removed)> wrote in message
>>>news(E-Mail Removed) ...
>>>
>>>
>>>>On Wed, 20 Jul 2005 00:50:07 -0500, "John C. Bollinger"
>>>><(E-Mail Removed)> wrote or quoted :
>>>>
>>>>
>>>>
>>>>>>Checking the source again it says "FORTRAN only has reference mode;
>>>>
>>>>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.

>>
>>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).


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.


--
Dale King
 
Reply With Quote
 
AndyRB
Guest
Posts: n/a
 
      07-24-2005
> 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.

>
> 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.
>
> --
> Dale King


 
Reply With Quote
 
Dale King
Guest
Posts: n/a
 
      07-27-2005
AndyRB wrote:
>>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.


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

>>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?


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.

--
Dale King
 
Reply With Quote
 
AndyRB
Guest
Posts: n/a
 
      07-27-2005
> > 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 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.

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Call by value vs. Call by reference Saeed Amrollahi C++ 10 07-15-2008 09:05 PM
difference b/w call by reference and call by pointer ravi C Programming 10 02-23-2007 10:57 AM
asp.net 2005 question re: "reference to a non-shared member requires an object reference" ce ASP .Net 1 06-23-2005 09:15 PM
web reference interfering with reference to component Dude ASP .Net 0 11-09-2004 11:53 AM
How to tell if a reference is project or file reference from within the IDE? Darren ASP .Net 0 10-11-2004 12:51 AM



Advertisments