Velocity Reviews - Computer Hardware Reviews

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

Reply
Thread Tools

call by reference

 
 
Pete Barrett
Guest
Posts: n/a
 
      07-03-2005
On 3 Jul 2005 10:07:15 GMT, http://www.velocityreviews.com/forums/(E-Mail Removed) wrote:

>You have a point, but if saying "Java has call by reference" makes
>them think they can change passed-in object references as well as
>the objects to which they point -- since this would be possible in
>other languages that have something called "call by reference" --
>well, that's not so good.
>

Well... do they? I guess you can ask them tomorrow. <g>

>
>This sounds good too, but I know that many things about Java made more
>sense to me when I understood that Java has two kinds of variables,
>primitives and references, and if you declare var1 as "Object var1",
>var1 is not an Object *but a reference to an Object*. Once I started
>thinking in this way, a lot of stuff that had previously seemed
>strange ("new Object[10]" doesn't actually create 10 Objects, e.g.,
>and "Object var2 = var1" doesn't make a copy of var1) suddenly made
>perfect sense.
>
>"YMMV", maybe. Or maybe this isn't the kind of thing you meant when
>you said that HLLs are supposed to shield us from details.


It is what I meant, but you have a point as well - namely, that
someone who understands the language at the higher level expects
specific behaviour, and when it actually behaves differently, a
knowledge of the lower level behaviour helps in understanding why.

Nevertheless, I think that the fact that it does help is an
imperfection in the design of Java (and pretty well all other
programming languages for that matter). Ideally, the behaviour of a
(high level) programming language should be defined, and be
understandable, without reference to the implementation (and to be
fair to Java, it does try).


Pete Barrett
 
Reply With Quote
 
 
 
 
Chris Smith
Guest
Posts: n/a
 
      07-03-2005
Pete Barrett <(E-Mail Removed)> wrote:
> Nevertheless, I think that the fact that it does help is an
> imperfection in the design of Java (and pretty well all other
> programming languages for that matter). Ideally, the behaviour of a
> (high level) programming language should be defined, and be
> understandable, without reference to the implementation (and to be
> fair to Java, it does try).


I don't think that the distinction between objects and references really
does fall into the category of implementation. The low-level
implementation changed drastically between the Sun reference
implementations of versions 1.1 and 1.2, and this had no visible effect
on program behavior aside from improving performance. The JLS does
define a consistent behavior that was maintained despite a drastic
change.

We need to distinguish between problem domain and solution domain here.
Languages become better by moving the solution domain closer to the
problem domain. However, it's fundamental to problem domains that we
make distinctions between whether we're using the same entity or a
different one. You seem to have ambitions to raise programming
languages to such a high level that these problem-domain distinctions
are not representable in the solution space. I have to look at that as,
at the very least, counterproductive to solving real-world problems.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
 
 
 
Patricia Shanahan
Guest
Posts: n/a
 
      07-03-2005
Chris Smith wrote:
> Pete Barrett <(E-Mail Removed)> wrote:
>
>>Nevertheless, I think that the fact that it does help is an
>>imperfection in the design of Java (and pretty well all other
>>programming languages for that matter). Ideally, the behaviour of a
>>(high level) programming language should be defined, and be
>>understandable, without reference to the implementation (and to be
>>fair to Java, it does try).

>
>
> I don't think that the distinction between objects and references really
> does fall into the category of implementation. The low-level
> implementation changed drastically between the Sun reference
> implementations of versions 1.1 and 1.2, and this had no visible effect
> on program behavior aside from improving performance. The JLS does
> define a consistent behavior that was maintained despite a drastic
> change.
>
> We need to distinguish between problem domain and solution domain here.
> Languages become better by moving the solution domain closer to the
> problem domain. However, it's fundamental to problem domains that we
> make distinctions between whether we're using the same entity or a
> different one. You seem to have ambitions to raise programming
> languages to such a high level that these problem-domain distinctions
> are not representable in the solution space. I have to look at that as,
> at the very least, counterproductive to solving real-world problems.
>


I think the whole situation would have been a lot clearer if the Java
developers had not tried to hide the fact that it is a heavily pointer
based language. Of course, it would have been necessary to explain that
Java pointers are much saner and safer than C pointers.

If what are called "references" in Java had been called "pointers", it
would have been obvious that all expressions and variables in Java are
either primitives or pointers, and both get passed by value.

Patricia
 
Reply With Quote
 
rdguru
Guest
Posts: n/a
 
      07-04-2005
shall i get a sample program & jsp for online banking payment system

 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      07-04-2005
George Cherry <(E-Mail Removed)> wrote:
> class TestPassByValue3 {
> private static void change(StringBuilder s) {
> s.replace(0, 3, "New");
> }
>
> public static void main(String[] args) {
> StringBuilder a = new StringBuilder("Old");
> change(a);
> System.out.println(a);
> }
> }


It's perhaps not a good idea to call this "TestPassByValue3", since the
result does not in ANY WAY depend on whether Java implements pass by
value or not. If you want to determine that, you need to use the lvalue
of the parameter. That's what I was trying to make clear all this time.
Your example is equivalent to the two examples of indirect values in my
original post, where the parameter passing mechanism is completely
irrelevant.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
George Cherry
Guest
Posts: n/a
 
      07-04-2005

"Chris Smith" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed).. .
> George Cherry <(E-Mail Removed)> wrote:
>> class TestPassByValue3 {
>> private static void change(StringBuilder s) {
>> s.replace(0, 3, "New");
>> }
>>
>> public static void main(String[] args) {
>> StringBuilder a = new StringBuilder("Old");
>> change(a);
>> System.out.println(a); //Prints "New"
>> }
>> }

>
> It's perhaps not a good idea to call this "TestPassByValue3", since the
> result does not in ANY WAY depend on whether Java implements pass by
> value or not. If you want to determine that, you need to use the lvalue
> of the parameter. That's what I was trying to make clear all this time.
> Your example is equivalent to the two examples of indirect values in my
> original post, where the parameter passing mechanism is completely
> irrelevant.


Okay, I see what you mean, but the purpose of
the above example was to show the op that passing
by value does NOT preclude the called method from
modifying an object on the heap referenced by
the parameter. Your first example

class TestPassByValue {
private static void change(String s) {
s = "New";
}

public static void main(String[] args) {
String a = "Old";
change(a);
System.out.println(a); //Prints "Old"
}
}

could give that misunderstanding. The reason
that your example is, I think, subject to confusing
the op about that is that you used a parameter
which referenced an immutable object. Yes,
your example does show that the assignment
to the formal by the called method does not
change the actual parameter in the caller's method,
but I think there is less confusing way to show this,
which follows.

The following example would have demonstrated
what you demonstrated without introducing the
possible confusion which I think your example could
cause.

class TestPassByValue4 {
private static void change(int i) {
i = i + 1;
System.out.println(i); //Prints 1
}

public static void main(String[] args) {
int i = 0;
change(i);
System.out.println(i); //Prints 0
}
}

Does what I just said make any pedagogical sense?

Boy, are we beating this subject to death, or what.

George W. Cherry


 
Reply With Quote
 
Andrew Thompson
Guest
Posts: n/a
 
      07-04-2005
On Sun, 03 Jul 2005 20:13:53 -0400, rdguru wrote:

> shall i get a sample program & jsp for online banking payment system


<I'll bight>
No.
</I'll bight>

--
Andrew Thompson
http://www.PhySci.org/codes/ Web & IT Help
http://www.PhySci.org/ Open-source software suite
http://www.1point1C.org/ Science & Technology
http://www.LensEscapes.com/ Images that escape the mundane
 
Reply With Quote
 
Chris Smith
Guest
Posts: n/a
 
      07-04-2005
George Cherry <(E-Mail Removed)> wrote:
> could give that misunderstanding. The reason
> that your example is, I think, subject to confusing
> the op about that is that you used a parameter
> which referenced an immutable object.


Okay, revised example:

class TestPassByValue
{
private static void change(Date dd)
{
dd = new Date();
}

public static void main(String[] args)
{
Date d = new Date(0L);
change(d);
System.out.println(d); // Jan 1, 1970
}
}

Your example was equivalent, except that the typical misunderstanding
goes something like "primitives are passed by value; objects are passed
by reference", so using a primitive doesn't end up demonstrating
anything either.

--
www.designacourse.com
The Easiest Way To Train Anyone... Anywhere.

Chris Smith - Lead Software Developer/Technical Trainer
MindIQ Corporation
 
Reply With Quote
 
Pete Barrett
Guest
Posts: n/a
 
      07-04-2005
On Sun, 3 Jul 2005 12:19:41 -0600, Chris Smith <(E-Mail Removed)>
wrote:

>I don't think that the distinction between objects and references really
>does fall into the category of implementation. The low-level
>implementation changed drastically between the Sun reference
>implementations of versions 1.1 and 1.2, and this had no visible effect
>on program behavior aside from improving performance. The JLS does
>define a consistent behavior that was maintained despite a drastic
>change.
>

Well, I think it does, but it's really just a matter of semantics.
What you call low level or implementation details, is a bit lower
level than what I call low level!

>We need to distinguish between problem domain and solution domain here.
>Languages become better by moving the solution domain closer to the
>problem domain. However, it's fundamental to problem domains that we
>make distinctions between whether we're using the same entity or a
>different one. You seem to have ambitions to raise programming
>languages to such a high level that these problem-domain distinctions
>are not representable in the solution space. I have to look at that as,
>at the very least, counterproductive to solving real-world problems.


I have no ambitions left, I assure you <g>. But it does seem to me
that over the past 30 years the tendency has been for practical
programming languages to more and more hide details such as these from
the programmer. I may be wrong, but it looks to me as if the designers
of Java would ideally like to have shielded the programmer from
needing to know that eg. creating an object sets aside space for it in
memory.

Pete Barrett
 
Reply With Quote
 
Mike Schilling
Guest
Posts: n/a
 
      07-04-2005

"Patricia Shanahan" <(E-Mail Removed)> wrote in message
news:csWxe.436$(E-Mail Removed) k.net...
>
> I think the whole situation would have been a lot clearer if the Java
> developers had not tried to hide the fact that it is a heavily pointer
> based language. Of course, it would have been necessary to explain that
> Java pointers are much saner and safer than C pointers.


Yes, 100 times yes. In fact a pointer in Java is *exactly* the same as a
pointer in Pascal; it's how you access a dynamically created object.


 
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