programming concepts > specific languages
ryan...@hotmail.com
quite obvious it is a waste of time to get all excited about different
languages when you haven't nailed down the programming concepts that
transcend all languages.
My question is, knowing I need to focus on the concepts, what advice
can you give for books, websites, or anything that doesn't focus on
particular languages?
I want to be better than some of these people who are just passing
through courses. Is it better for me to mainly get the concepts? Are
there any good books to help with understanding the concepts and
mathematics?
Is this not the primary grade of a good programmer? To be able to jump
to languages and only need to learn some syntax and limits that are
specific to that language. To know the concepts and the mathematics it
seems is paramount to succeeding and I have seen some really good
articles that argue this over learning the languages.
For me the languages part is easy, its the concepts that sometimes take
time to grasp, like advanced array techniques, data structures,
sorting, and efficiency in algorithms.
- Thanks
Oliver Wong
news:1130884022.0...@g44g2000cwa.googlegroups.com...
The ease of jumping from language to language depends on how similar the
two languages are, of course. Jumping from Java to C# is relatively easy.
Java to C/C++ a bit harder. Java to COBOL, harder. Java to Scheme, even
harder yet.
That being said, any "good" university-level computer science program
will probably focus on the concepts rather than any particular language.
As for books/websites/anything, I don't have any specific
recommendations, but if you wish to get employed, you'd probably do well to
learn the concepts behind Object Oriented Programming (OOP), and perhaps AOP
(Aspect Oriented Programming). The latter is relatively new, and some say
might supplement or replace OOP.
- Oliver
Jon Harrop
> Hi. So it finally hit me and maybe I have been denying it but it is
> quite obvious it is a waste of time to get all excited about different
> languages when you haven't nailed down the programming concepts that
> transcend all languages.
There aren't actually that many concepts that transcend all languages.
Perhaps the most important such concept (from a practical point of view) is
that of algorithmic complexity, particularly asymptotic algorithmic
complexity (e.g. big "O" notation).
> My question is, knowing I need to focus on the concepts, what advice
> can you give for books, websites, or anything that doesn't focus on
> particular languages?
"Introduction to Algorithms" by Cormen et al. is an excellent discussion of
a variety of data structures and algorithms and includes a very good
description of algorithmic complexity.
My OCaml book contains a similar discussion of complexity theory but the
remainder is mostly OCaml specific.
> I want to be better than some of these people who are just passing
> through courses. Is it better for me to mainly get the concepts? Are
> there any good books to help with understanding the concepts and
> mathematics?
Knuth's bible "The Art of Computer Programming" contains excellent
descriptions of many parts of mathematics than overlap with computer
science (e.g. floating point arithmetic) but it is not for the faint
hearted!
> Is this not the primary grade of a good programmer? To be able to jump
> to languages and only need to learn some syntax and limits that are
> specific to that language. To know the concepts and the mathematics it
> seems is paramount to succeeding and I have seen some really good
> articles that argue this over learning the languages.
I would say that "a good programmer" must have tried a variety of different
languages. The differences between languages are not only syntactic. Some
languages expose the machine at a very low level (e.g. Fortran and C),
Other languages abstract away the machine to improve safety and remove many
tedious programming chores like manual memory deallocated (e.g. Java).
Other languages take a more clinical view of data transformations and
include constructs like pattern matching and functionality like static type
checking (e.g. SML and OCaml). Other languages replace the notion of
evaluation, for example with the repeated application of replacement rules
(e.g. Mathematica). Other languages are search oriented to make them more
suitable for combinatorical searching and optimisation problems (e.g.
Prolog). There are many other programming paradigms that you can also
learn, including industrial fads like Aspect-Oriented Programming (AOP)
that, although most likely useless, may make you more employable (but not a
"good programmer", IMHO).
> For me the languages part is easy, its the concepts that sometimes take
> time to grasp, like advanced array techniques, data structures,
> sorting, and efficiency in algorithms.
You should certainly learn about such things but it is also essential to
learn about the developments that have been made in programming languages
over the last half century. The differences between languages are every bit
as wild and productive as the differences between algorithms.
--
Dr Jon D Harrop, Flying Frog Consultancy
http://www.ffconsultancy.com
shiv_k...@yahoo.com
-------
Regards ,
C#, VB.NET , SQL SERVER , UML , DESIGN Patterns Interview question book
http://www.geocities.com/dotnetinterviews/
My Interview Blog
http://spaces.msn.com/members/dotnetinterviews/
Richard Heathfield
> Hi. So it finally hit me and maybe I have been denying it but it is
> quite obvious it is a waste of time to get all excited about different
> languages when you haven't nailed down the programming concepts that
> transcend all languages.
I disagree. Excitement is a driving force which helps you towards the
concepts you're seeking, so it's a Good Thing. After all, it's much easier
to understand a programming concept if you have a way to express it to a
computer.
> My question is, knowing I need to focus on the concepts, what advice
> can you give for books, websites, or anything that doesn't focus on
> particular languages?
Apart from Cormen, consider Knuth's "The Art of Computer Programming" as
well - although this is highly mathematical in its approach. And even Knuth
sometimes slips into a programming language (he devises a made-up
architecture and gives examples in a made-up assembly language for that
architecture), because sometimes you just gotta.
"Code Complete" (Steve McConnell) is another excellent language-blind book,
but it focuses more on code *quality* than actual algorithms. For its
language blindness it takes the approach of giving examples in a particular
language, but the language is drawn from a selection of various different
ones.
Is it a useful book to you? Well, if I may use an analogy for a moment,
"Code Complete" book won't show you how to make the lion sit up on its hind
paws and beg, but it does explain how to fit lion-proof sleeves to your
coat. Personally, I think a budding lion-tamer can benefit from both kinds
of book!
> I want to be better than some of these people who are just passing
> through courses.
That won't be difficult. Why not set your sights a little higher?
> For me the languages part is easy, its the concepts that sometimes take
> time to grasp, like advanced array techniques, data structures,
> sorting, and efficiency in algorithms.
And those are the very things on which you need to concentrate. Either
Cormen et al, or Knuth, or both. And, of course, your brain, for which
there is no substitute. :-)
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)
Arthur J. O'Dwyer
On Tue, 1 Nov 2005 ryan...@hotmail.com wrote:
>
> Hi. So it finally hit me and maybe I have been denying it but it is
> quite obvious it is a waste of time to get all excited about different
> languages when you haven't nailed down the programming concepts that
> transcend all languages.
True. But what Richard Heathfield says is also true. One bit of advice
you might find useful: Try to learn a few radically different languages
from books or websites (or people!) who know what they're good for, and
you can probably pick up a lot of "concepts" by osmosis. Then try to
apply the concepts from one language to another.
For example, learn C++; then see how knowing about constructors and
destructors can make programming in C easier. Learn a functional language
such as ML or Ocaml; then think about how you might implement closures,
or higher-order functions, or programming with continuations, in a
lower-level language. Think about why recursion is helpful, even in
languages that provide iteration. Learn a vector-based language such as
Matlab, APL, or some Basics, and see how doing operations on many values
at the same time can speed up some algorithms.
This advice is /really/ skewed by my C background, so take it with a
grain of salt. Also, there are a lot of basic /algorithms/ --- quicksort,
Bresenham's line algorithm, hashing, stuff like that --- that you won't
learn by osmosis; you need to sit down intending to learn them, and then
use them a lot. IMHO.
HTH,
-Arthur
Oliver Wong
"Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.60-041....@unix49.andrew.cmu.edu...
>
> This advice is /really/ skewed by my C background, so take it with a
> grain of salt. Also, there are a lot of basic /algorithms/ --- quicksort,
> Bresenham's line algorithm, hashing, stuff like that --- that you won't
> learn by osmosis; you need to sit down intending to learn them, and then
> use them a lot. IMHO.
I don't know what Bresenham's line algorithm is, but while it may be
nice to know how to implement your own quicksort algorithm or hashtable data
structure, in practice you'll probably never implement these yourself. Any
non-trivial code library will provide an implementation for these common
tools.
Perhaps more important than knowing HOW to implement a hashtable is
knowing WHY a hashtable is useful. You have to be able to, given a problem,
know if a hashtable really is the best tool for the job. Sometimes it is.
Other times, a tree structure is more appropriate. You'll want to know how a
hashtable works, but you'll probably never need to build your own hashtable.
- Oliver
(I'm not implying that Arthur O'Dwyer meant otherwise; just clarifying a
point in his post.)
vishnuvyas
> Hi. So it finally hit me and maybe I have been denying it but it is
> quite obvious it is a waste of time to get all excited about different
> languages when you haven't nailed down the programming concepts that
> transcend all languages.
There are actually very few concepts that transcend all languages
beacause as the saying goes 'the devil *IS* in the details'. So its
best that you do learn it along with the languages. There are
defeciencies to learning without concrete implementations too because
for the sake of abstractions many authours tend to leave out a lot of
specifics that are required in the real world.
My advice would be that, you should learn to use more than one language
(start with Scheme and Java/Python) and slowly learn to grow out of it.
Once you have had enough exposure to a language it would be easy to see
past the details.
> My question is, knowing I need to focus on the concepts, what advice
> can you give for books, websites, or anything that doesn't focus on
> particular languages?
Apart from 'The Art of Computer Programming' I would also suggest
'Concrete Mathematics' by Knuth.
> I want to be better than some of these people who are just passing
> through courses. Is it better for me to mainly get the concepts? Are
> there any good books to help with understanding the concepts and
> mathematics?
Just getting the concepts without being able to write code isn't worth
it. So I would still stick on to learn the concepts along with a
language, but consider the language as a mere implementation detail and
learn to extract the concepts.
So on that account I would suggest 'Structure and Interpretation of
Computer Programs' (SICP). The website also has a bunch of video
lectures that you might find useful.
> Is this not the primary grade of a good programmer? To be able to jump
> to languages and only need to learn some syntax and limits that are
> specific to that language. To know the concepts and the mathematics it
> seems is paramount to succeeding and I have seen some really good
> articles that argue this over learning the languages.
Languages are not simply syntax. It is *very* important to know the
basic concepts and the mathematics behind it, but not too much. (Take
for example denotational semantics.. if thats the kinda of math you are
talking about I guess thats not exactly required in knowing to write
programs,even good ones).
The essence of being a good programmer is being able to use your tools
effectively and for that you would require the knowledge of tools,
which unfortunately is too specific to the tools you are using. So it
is both important to concentrate on the details as well as be able to
abstract away whats not required and internalise the concepts.
> For me the languages part is easy, its the concepts that sometimes take
> time to grasp, like advanced array techniques, data structures,
> sorting, and efficiency in algorithms.
Well.. there again, languages due to their syntax and limitations make
you think differently about your concepts. i.e, provide new
perspectives. Take for example C, where you have pointers, that gives
you immense control over the code you are writing and thats a concept
you have to learn (things like indirection), however thats again C
specific. You probably would never have to actually learn about
pointers if you are just doing java all along. And you usually won't
find such things in language blind (neutral?) books.
But having said this, there are things that are truly language neutral.
Like design of programs, thinking in terms of objects (OO), writing
reliable code (error handling) etc.. but unfortunately the best way to
learn these things is by doing them (practice makes perfect), and you
can't really practice by just thinking about the concepts can you?
Cheers
Vishnu Vyas
Jon Harrop
> This advice is /really/ skewed by my C background, so take it with a
> grain of salt. Also, there are a lot of basic /algorithms/ --- quicksort,
> Bresenham's line algorithm, hashing, stuff like that --- that you won't
> learn by osmosis; you need to sit down intending to learn them, and then
> use them a lot. IMHO.
LOL. I wouldn't say that I use Bresenham's line algorithm a "lot". ;-)
ryan...@hotmail.com
I was not sure if there was a topic like this on here probably but
maybe not.
Anyways I have a good launching pad to being a real programmer although
I have already started I was doing some things very wrong.
I have taken courses in Java and very little php, sql, transact sql.
I am now taking assembly (x86 linux based) so it has been a bit of
reality check about how much there actually is to coding.
I did know there were some differences in the languages besides syntax
but thanks for pointing the more important differences out.
So would I be right in summarizing my lesson here as know the concepts
and learn how to use the tools but make sure you grab the right tools
for the right job and always keep an open mind and dont be tied to a
language or a particular way of solving a problem.
I am finally starting to get serious about programming because I am
going to school for a computer science degree and I have to get a job
in the field. I see too many times beginners who are just not taking
the courses seriously and/or think they already know it. Even if its an
HTML course I still think it would be wise to dive into everything
about it and learn a lot. Plus a lot of guys seem to be addicted to
gaming (me not so much anymore) but thats just one of those habits I
have to break and realize there is a time to be an adult and make
something of yourself. Wow okay thats enough.
THANKS AGAIN!!!
- Ryan
Jon Harrop
> But having said this, there are things that are truly language neutral.
>
> Like design of programs, thinking in terms of objects (OO), writing
> reliable code (error handling) etc.
I'd have said that program design, objects, reliability and error handling
were actually very language specific. The design and structure of a program
depends upon the methods of encapsulation available (e.g. nothing in C,
modules in SML, objects in Java). Thinking in terms of objects is essential
for Java but worse than ignorance for OCaml programming. Reliability is
different in the presence of static checking or the use of dynamic typing
(e.g. unit testing). Error handling is different in the presence of
exceptions and, even then, depends upon the way in which exceptions are
provided.
So I certainly agree that most things are language dependent. Even data
structures and algorithms are different in functional vs imperative
programming. The abstract concepts in the widest sense remain the same,
e.g. the concept of a balanced binary tree, but the implementations are
quite different.
Barry
<ryan...@hotmail.com> wrote in message
news:1130980629....@g47g2000cwa.googlegroups.com...
Many of "us" were game players, and still are :-). But it is really fun
when you can write them too.
Oliver Wong
news:1130969976.8...@g49g2000cwa.googlegroups.com...
> Take for example C, where you have pointers, that gives
> you immense control over the code you are writing and thats a concept
> you have to learn (things like indirection), however thats again C
> specific. You probably would never have to actually learn about
> pointers if you are just doing java all along.
Java has consistent, but non-intuitive, rules involving passing by
value/passing by reference. A lot of beginning Java programmers don't
understand why when they pass primitive types (int, float, char, etc.) they
seem to be passed by values, and yet when they pass objects, they seem to be
passed by reference.
Actually, everything is being passed by value; it's just that when
you're "passing an object", you're actually passing a reference to that
object (and you're passing that reference by value).
I find that it helps a lot to understand the underlying memory model of
a typical RAM machine to "get" Java's passing rules. You don't need to know
much, but you do need a concept of something like a giant array representing
RAM (i.e. each slot has an address), and that some locations in RAM don't
actually contain the desired value, but instead contain the address of the
desired value. An introductory course to machine architectures and "high
level" assembly would probably help a lot.
So I think it may actually be very helpful to learn about pointers if
you're a Java programmer.
- Oliver
Michael Wojcik
In article <Vxaaf.74218$S4.9322@edtnps84>, "Oliver Wong" <ow...@castortech.com> writes:
>
> I don't know what Bresenham's line algorithm is,
GIYF, of course. It's an algorithm for determining the contiguous
set of cells in a rectangular array that most closely fit a line
drawn through that array. It's a 2D line-plotting algorithm, in
other words.
> but while it may be
> nice to know how to implement your own quicksort algorithm or hashtable data
> structure, in practice you'll probably never implement these yourself. Any
> non-trivial code library will provide an implementation for these common
> tools.
Sometimes a library implementation isn't suitable. I worked on a
project where a performance-critical piece of code had to serially
process many relatively small (on the order of 10-100 items) sets of
data, and part of processing involved sorting the items in a set. A
hand-coded inline sort (I used Shell, with an inner selection, IIRC,
but any low-overhead sort would do) was the only adequate option; a
library routine with a comparison delegate would have had far too
much overhead.
And having to write a sort is not the only reason for knowing how one
is implemented. I once watched a couple of developers benchmark a
long-running sort step on an 8-way SMP box. The sort they were using
wasn't parallelized, so it only used one of those processors, and of
course they got no scaling whatsoever by moving to the SMP system.
An understanding of multiway mergesort in a situation like that would
definitely be useful.
Certainly many problems can be solved by someone using black-box
tools, but IMO that does not diminish the benefit of knowing how tools
work.
--
Michael Wojcik michael...@microfocus.com
The antics which have been drawn together in this book are huddled here
for mutual protection like sheep. If they had half a wit apiece each
would bound off in many directions, to unsimplify the target. -- Walt Kelly
Michael Wojcik
In article <43696701$0$27998$ed26...@ptn-nntp-reader02.plus.net>, Jon Harrop <use...@jdh30.plus.com> writes:
>
> The design and structure of a program
> depends upon the methods of encapsulation available (e.g. nothing in C,
> modules in SML, objects in Java).
Jon, could you *please* limit the programming-language flamebait to,
say, one post a day? I'm as fond of SML as the next fellow, but I
don't need to see it featured in an eternal religious war here.
alt.advocacy.ocaml is yours to newgroup.
(Claiming that there is no facility for encapsulation in C
demonstrates a seriously impoverished understanding of that language.
And that's all I'm going to say about *that*.)
--
Michael Wojcik michael...@microfocus.com
Arthur J. O'Dwyer
On Thu, 3 Nov 2005, Michael Wojcik wrote:
>
> "Oliver Wong" <ow...@castortech.com> writes:
>>
>> I don't know what Bresenham's line algorithm is,
>
> GIYF, of course. It's an algorithm for determining the contiguous
> set of cells in a rectangular array that most closely fit a line
> drawn through that array. It's a 2D line-plotting algorithm, in
> other words.
...Or N-D, although the number of cases you have to handle goes up
as 2**N, I think. But there are also quite a few applications of the
algorithm that don't on the face of them involve /drawing/ lines ---
anything where you want to compute something discrete that, when graphed,
approximates a straight line will do. I knew a couple of examples at
some point, and then forgot them. :(
>> but while it may be
>> nice to know how to implement your own quicksort algorithm or hashtable data
>> structure, in practice you'll probably never implement these yourself. Any
>> non-trivial code library will provide an implementation for these common
>> tools.
[...]
> Certainly many problems can be solved by someone using black-box
> tools, but IMO that does not diminish the benefit of knowing how tools
> work.
Yes. In particular, quicksort (or mergesort) teaches you about
divide-and-conquer algorithms, and hash tables, IMO, are more about
the "engineering" side --- the idea that you can get essentially O(1)
operations by a judicious use of big enough data structures.
-Arthur
vishnuvyas
Jon Harrop wrote:
> vishnuvyas wrote:
> > But having said this, there are things that are truly language neutral.
> >
> > Like design of programs, thinking in terms of objects (OO), writing
> > reliable code (error handling) etc.
>
> I'd have said that program design, objects, reliability and error handling
> were actually very language specific. The design and structure of a program
> depends upon the methods of encapsulation available (e.g. nothing in C,
Nothing in C? Instead of going through what C provides, why don't you
just take a look at GTK? Thats purely OO design within the limits of C.
C does provide to a certain degree forms of encapsulation (assuming you
aren't talking about things like access rules). But not too much. But
"nothing" is well, in my opinion an understatemnt.
> modules in SML, objects in Java). Thinking in terms of objects is essential
> for Java but worse than ignorance for OCaml programming. Reliability is
> different in the presence of static checking or the use of dynamic typing
Presence of static typing doesn't affect the reliability of code beyond
a certain point (and that being very marginal). Writing reliable code
is more on practices and discipline rather than what language you are
using. C is statically checked but that doesn't cause your programs to
stop segfaulting/become security hazards/whatever. The reason, static
checks have very little to do with reliability.
Cheers
Vishnu
Jon Harrop
>> modules in SML, objects in Java). Thinking in terms of objects is
>> essential for Java but worse than ignorance for OCaml programming.
>> Reliability is different in the presence of static checking or the use of
>> dynamic typing
>
> Presence of static typing doesn't affect the reliability of code beyond
> a certain point (and that being very marginal). Writing reliable code
> is more on practices and discipline rather than what language you are
> using. C is statically checked but that doesn't cause your programs to
> stop segfaulting/become security hazards/whatever. The reason, static
> checks have very little to do with reliability.
C is a far cry from modern static type systems (e.g. SML, OCaml, Haskell,
Clean), which greatly improve program reliability.
Jon Harrop
> as 2**N, I think. But there are also quite a few applications of the
> algorithm that don't on the face of them involve /drawing/ lines ---
> anything where you want to compute something discrete that, when graphed,
> approximates a straight line will do. I knew a couple of examples at
> some point, and then forgot them. :(
Ray casting. IIRC, there is also an octree equivalent.
Tim Rentsch
> In article <43696701$0$27998$ed26...@ptn-nntp-reader02.plus.net>,
> Jon Harrop <use...@jdh30.plus.com> writes:
> >
> > The design and structure of a program
> > depends upon the methods of encapsulation available (e.g. nothing in C,
> > modules in SML, objects in Java).
>
> Jon, could you *please* limit the programming-language flamebait to,
> say, one post a day? I'm as fond of SML as the next fellow, [...]
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
If the next fellow is Jon I bet you aren't. :)
Gerry Quinn
says...
> Java has consistent, but non-intuitive, rules involving passing by
> value/passing by reference. A lot of beginning Java programmers don't
> understand why when they pass primitive types (int, float, char, etc.) they
> seem to be passed by values, and yet when they pass objects, they seem to be
> passed by reference.
>
> Actually, everything is being passed by value; it's just that when
> you're "passing an object", you're actually passing a reference to that
> object (and you're passing that reference by value).
This argument is gibberish, in my view. When you pass a reference by
value you are passing a reference, just as when you pass a pointer by
value you are passing a pointer. Parameters are ALWAYS passed in
memory that ultimately holds values and can hold nothing else, so the
Java interpretation "everything is passed by value" is essentially
meaningless, designed only to disguise the fact that this language
sometimes passes by value and sometimes by reference, depending on
whether the object passed is a primitive or not.
Call it consistent if you want. Any system can be called consistent,
just as any parameter can be said to be passed by value.
- Gerry Quinn
Jon Harrop
> This argument is gibberish, in my view. When you pass a reference by
> value you are passing a reference, just as when you pass a pointer by
> value you are passing a pointer. Parameters are ALWAYS passed in
> memory that ultimately holds values and can hold nothing else, so the
> Java interpretation "everything is passed by value" is essentially
> meaningless, designed only to disguise the fact that this language
> sometimes passes by value and sometimes by reference, depending on
> whether the object passed is a primitive or not.
>
> Call it consistent if you want. Any system can be called consistent,
> just as any parameter can be said to be passed by value.
Very true. However, my main gripe with Oliver Wong's statements is with his
conclusion "I think it may actually be very helpful to learn about pointers
if you're a Java programmer". Pointers are completely irrelevant. Java
programmers should know about references, not pointers.
Richard Harter
wrote:
Snicker. :)
Richard Harter, c...@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
I started out in life with nothing.
I still have most of it left.
Oliver Wong
"Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
news:MPG.1dd53c78a...@news.indigo.ie...
> In article <g9qaf.74536$S4.33171@edtnps84>, ow...@castortech.com
> says...
>
>> Java has consistent, but non-intuitive, rules involving passing by
>> value/passing by reference. A lot of beginning Java programmers don't
>> understand why when they pass primitive types (int, float, char, etc.)
>> they
>> seem to be passed by values, and yet when they pass objects, they seem to
>> be
>> passed by reference.
>>
>> Actually, everything is being passed by value; it's just that when
>> you're "passing an object", you're actually passing a reference to that
>> object (and you're passing that reference by value).
>
> This argument is gibberish, in my view. When you pass a reference by
> value you are passing a reference, just as when you pass a pointer by
> value you are passing a pointer. Parameters are ALWAYS passed in
> memory that ultimately holds values and can hold nothing else, so the
> Java interpretation "everything is passed by value" is essentially
> meaningless, designed only to disguise the fact that this language
> sometimes passes by value and sometimes by reference, depending on
> whether the object passed is a primitive or not.
Maybe we're using different definitions for "pass by reference". To me,
"pass by value" means that the computer will make a copy of the value, and
then give that copy to the method. There is no way for the method to modify
the original value. "Pass by reference", in contrast, means that the
computer will give the address of the value to the method, so that when the
method modifies the value pointed to by that address, the original value
does indeed get modified.
So consider this short Java code snippet:
<code>
public static void main() {
String myString = "String A";
manipulateString(myString);
System.out.println(myString);
}
public static void manipulateString(String stringToManipulate) {
stringToManipulate = "String B";
}
</code>
"myString" is a reference to a String object. The reference itself
exists somewhere in memory (let's say at memory location 3), and the String
object exists somewhere in memory (let's sat at memory location 54). So if
you peered into RAM, at position 3, you'd see the value 54, and at position
54, you'd see the "String A" String object.
On the second line of the "main" method, a method invocation is being
made. What value gets passed along? If Java were "pass by reference", you'd
want to give the method the address of the reference, i.e. you'd pass the
value 3 along. Then the method would be able to change 3 so that it no
longer contains the vlaue "54" (the address of the "String A" String
object), but instead replace it with the value 164 (the address of the
"String B" String object). Then, upon returning from the function, on the
3rd line of the main function, the println function would once again receive
the value "3" (the address of the myString variable), see that it contains
164, dereferences that to get the String object there, and rpint "String B"
to the console.
What actually happens in Java though is "String A" gets printed out.
Why? Because Java is "pass by value".
On the second line, the value of the reference is passed along, not the
address, so the second method receives "54" and not "3". Therefore, it
cannot ever actually modify the contents of memory location 3, and therefore
it cannot ever change what object the "myString" reference points to.
- Oliver
Oliver Wong
"Jon Harrop" <use...@jdh30.plus.com> wrote in message
news:436b5306$0$63096$ed2e...@ptn-nntp-reader04.plus.net...
>
> However, my main gripe with Oliver Wong's statements is with his
> conclusion "I think it may actually be very helpful to learn about
> pointers
> if you're a Java programmer". Pointers are completely irrelevant. Java
> programmers should know about references, not pointers.
In my experience in tutoring other Computer Science students, I found it
helpful to actually talk about memory addresses. That is why I feel it is
helpful to bring up C-style pointers instead of just Java style references.
Although probably impossible to prove one way or the other, I have the
strong belief that people who "get" Java references also know how pointers
work. Whether this is related or coincidental, I guess is up for debate.
- Oliver
GRios
I don't like the ideia many use, relating programming to C, C++ and the
like.
Programming is nothing to do about C, C++, Java, X, Y, Z, Lisp, blah
blah.
When some asks things like "how to be a better C programmer,?" i judge
he does not deserve to C nor be a programmer. Since, i my opnion, C is
about coding; that question is non-sense.
I proper question is: how to be a better programmer. That's the
questions i could try to answer. If it was that, i would suggest: MATH
my friend, MATH.
Here is the list i used towards my education, i pass it you. On coding
and programming, also.
Coding:
The C Programming Language (ANSI C), Brian Kernigha, Dennis M. Ritchie
Programming:
A Logical Approach to Discrete Math, David Gries (This book was my
introduction).
The Science Of Programming, David Gries,
Predicate Calculus and Program Semantics, E. W. Disjkstra
A Discipline of Programming, E. W. Dijkstra
Formal Development Of Programming and Proofs, E. W. Dijkstra
Of course, i cannot apply them "ipsis litteris", but the awareness of
such knownledge is what makes the difference between a Gentleman and
Polished Programmer and the Hackers (often very stupid).
I hope it helps.
BTW: in the next month i will be releasing a set of tools i had
interested and could not found anything on the internet i could enjoy
(due to technical quality or lecensing matters). I am searching folks
who could interest in testing them under stress condition. I am very
confident in my work and would like to share them with the community.
Oliver Wong
news:1131139844.0...@f14g2000cwb.googlegroups.com...
>
> I proper question is: how to be a better programmer. That's the
> questions i could try to answer. If it was that, i would suggest: MATH
> my friend, MATH.
I think that statement is a little bit misleading. It isn't
inconceivable that someone who did poorly at calculus, trigonometry,
statistics and probability could be a very gifted programmer. Of course,
given their weakness, they might not be well suited for writing physics
engines for games, but may be very capable of designing and implementing
enterprise web applications, reporting software, accounting systems,
parsers, compilers and peer to peer Internet applications just to list a few
domains.
I think to be a good programmer, you need to be good at abstract
thinking, good at logical deductions and able to think of and address the
"corner cases" of a problem which don't arise often, but which can come back
to haunt you if you don't have a plan with how to deal with them. Some of
these overlap with math, which is why people who are good at math are
typically good at computer science and vice versa, but the relation between
the two is weaker than you're implying, I think.
- Oliver
GRios
science background; i was thingk about discrete math.
By reading the books i suggested, it is easy to realize that. I they
were really helpful for me.
Arctic Fidelity
news:L5Saf.106932$ir4.94140@edtnps90:
> I think to be a good programmer, you need to be good at abstract
> thinking, good at logical deductions and able to think of and address
> the "corner cases" of a problem which don't arise often, but which can
> come back to haunt you if you don't have a plan with how to deal with
> them. Some of these overlap with math, which is why people who are
> good at math are typically good at computer science and vice versa,
> but the relation between the two is weaker than you're implying, I
> think.
Well, from what I can understand, the nearest discipline of study next
to programming is simply formal logic. Mathematics, in reality, is just
an application of logic to specific problems, using a specific language
(I would call them some form of numerics, but I don't know the right
term) to describe logical thought.
In reality, any programming language is really just a language, the same
as English, Russian, Chinese, Latin, or anything else. Most programming
languages have a strict syntax however, which differentiates them from
something like English.
Nonetheless, the basic problem or road block to achieving a goal which
requires the use of computer programming is rarely the language itself,
in my experience. Rather, I find that it is the inability to reason, to
use formal logic. As a result, I look at programming as the translation
of abstract logical thought to some formal language in a form that a
computer is capable of processing. That's it.
In a nutshell, Programming is just another word for the lost art of
thinking.
- Arctic Fidelity
Jon Harrop
> Although probably impossible to prove one way or the other, I have the
> strong belief that people who "get" Java references also know how pointers
> work. Whether this is related or coincidental, I guess is up for debate.
I also think that people will understand Java better if they know about
pointers. However, they also need to know about copying GCs and the
implications in terms of inequalities between references.
(I'm not sure what Java specifies, but I'm assuming you cannot compare
references for <, > etc.)
Michael Wojcik
In article <Xns9705D0DEFDBEAsp...@216.196.97.131>, Arctic Fidelity <sp...@sacrificumdeo.net> writes:
> "Oliver Wong" <ow...@castortech.com> wrote in
> news:L5Saf.106932$ir4.94140@edtnps90:
>
> > I think to be a good programmer, you need to be good at abstract
> > thinking, good at logical deductions and able to think of and address
> > the "corner cases" of a problem which don't arise often, but which can
> > come back to haunt you if you don't have a plan with how to deal with
> > them.
I tend to agree, based only on personal experience and anecdote
(which hardly constitute evidence, but this is Usenet). In my
experience, particularly as an undergraduate, the better programmers
(by the metric of producing clean, working code in a timely fashion)
were those who were disposed to examine a problem thoroughly and not
simply leap in with their first idea.
Some also had an inclination for mathematics (discrete or otherwise),
and no doubt in their case that tendency to analyze problems was
useful there as well; but others did not.
>
> Well, from what I can understand, the nearest discipline of study next
> to programming is simply formal logic.
Symbolic logic is a branch of discrete mathematics.
> Mathematics, in reality, is just
> an application of logic to specific problems,
*Applied* mathematics is the application of a formal system to
specific problems, but mathematics is more than simply application.
> In reality, any programming language is really just a language, the same
> as English, Russian, Chinese, Latin, or anything else. Most programming
> languages have a strict syntax however, which differentiates them from
> something like English.
More than just confines of syntax separates programming languages
from natural languages. Calling them "the same" is really not a
useful claim.
> In a nutshell, Programming is just another word for the lost art of
> thinking.
There are realms of dedicated, complex, abstract thought which are
largely unrelated to the kinds of intellectual work which are used in
programming. Programming is not an all-encompassing discipline.
--
Michael Wojcik michael...@microfocus.com
The guy who's fast in the mountain pass is the coolest.
-- _Initial D: Second Stage_
Gerry Quinn
says...
> news:MPG.1dd53c78a...@news.indigo.ie...
> So consider this short Java code snippet:
>
> <code>
> public static void main() {
> String myString = "String A";
> manipulateString(myString);
> System.out.println(myString);
> }
>
> public static void manipulateString(String stringToManipulate) {
> stringToManipulate = "String B";
> }
> </code>
> What actually happens in Java though is "String A" gets printed out.
> Why? Because Java is "pass by value".
>
> On the second line, the value of the reference is passed along, not the
> address, so the second method receives "54" and not "3". Therefore, it
> cannot ever actually modify the contents of memory location 3, and therefore
> it cannot ever change what object the "myString" reference points to.
This isn't what happens. The reasons strings in Java act as above is
because they are yet another category, immutable objects, that get
copied invisibly. The function gets the address of yet another copy of
the string, and performs a therefore useless manipulation of it.
Consider the following:
class Object
{
public int x;
};
public static void manipulateObject( Object objectToManipulate )
{
objectToManipulate.x = 10;
}
public static void manipulateString( String stringToManipulate )
{
stringToManipulate = "DEF";
}
String originalStr = new String( "ABC" );
String changedStr = originalStr;
manipulateString( changedStr );
Object originalOb = new Object();
originalOb.x = 5;
Object changedOb = originalOb;
manipulateObject( changedOb );
String output = originalStr + " " + changedStr + " ";
output = output + Integer.toString( originalOb.x ) + " ";
output = output + Integer.toString( changedOb.x );
System.out.println( output );
You get "ABC ABC 10 10"
Because Java is inconsistent.
- Gerry Quinn
Oliver Wong
"Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
>
> This isn't what happens. The reasons strings in Java act as above is
> because they are yet another category, immutable objects, that get
> copied invisibly. The function gets the address of yet another copy of
> the string, and performs a therefore useless manipulation of it.
>
> Consider the following:
>
> class Object
> {
> public int x;
> };
>
> public static void manipulateObject( Object objectToManipulate )
> {
> objectToManipulate.x = 10;
> }
>
> public static void manipulateString( String stringToManipulate )
> {
> stringToManipulate = "DEF";
> }
>
> String originalStr = new String( "ABC" );
> String changedStr = originalStr;
> manipulateString( changedStr );
>
> Object originalOb = new Object();
> originalOb.x = 5;
> Object changedOb = originalOb;
> manipulateObject( changedOb );
>
> String output = originalStr + " " + changedStr + " ";
> output = output + Integer.toString( originalOb.x ) + " ";
> output = output + Integer.toString( changedOb.x );
>
> System.out.println( output );
>
> You get "ABC ABC 10 10"
>
> Because Java is inconsistent.
Actually, I'd argue it's more like your code which is inconsistent.
Change the code that reads:
<oldCode>
public static void manipulateObject( Object objectToManipulate ) {
objectToManipulate.x = 10;
}
</oldCode>
to
<newCode>
public static void manipulateObject( Object objectToManipulate ) {
objectToManipulate = new Object(); //x defaults to 0 here
}
</newCode>
and the output will be "ABC ABC 5 5".
The reason I claim your code is inconsistent is that in one case you're
setting the reference (stringToManipulate) and in another case you're using
the reference to get the address of an particular field instance (named x in
the source code), and then setting 'x', rather than setting the reference.
- Oliver
Oliver Wong
> Excuse, but are you an engineer? When i say MATH, i, with a computer
> science background; i was thingk about discrete math.
Okay, sorry, I must have misunderstood you. My degree is in computer
science, not in engineering. My best friend has a degree in computer
engineering though, and I like to think that my code is typically more
elegant than his. ;)
- Oliver
Gerry Quinn
says...
> Actually, I'd argue it's more like your code which is inconsistent.
> Change the code that reads:
>
> <oldCode>
> public static void manipulateObject( Object objectToManipulate ) {
> objectToManipulate.x = 10;
> }
> </oldCode>
>
> to
>
> <newCode>
> public static void manipulateObject( Object objectToManipulate ) {
> objectToManipulate = new Object(); //x defaults to 0 here
> }
> </newCode>
>
> and the output will be "ABC ABC 5 5".
>
> The reason I claim your code is inconsistent is that in one case you're
> setting the reference (stringToManipulate) and in another case you're using
> the reference to get the address of an particular field instance (named x in
> the source code), and then setting 'x', rather than setting the reference.
But in both cases the natural interpretation is that I am manipulating
the object that is passed by reference (why did you call the function
manipulateString() in the first place if you did not intend that?).
The lines:
stringToManipulate = "DEF";
and
objectToManipulate.x = 10;
..both seem on the surface to be manipulating an object passed for that
purpose. But in the first case the string is never changed because
strings are immutable and there is a secret 'new' involved. Which
means your original explanation was wrong - you never mentioned this.
In the second case there is no secret 'new' because Object is mutable
and I am allowed change the object to which a reference is passed.
Primitives, objects, mutability - I rest my case that Java, if it is to
be called consistent, is consistent in an excessively complicated
fashion.
In C++ there's none of this bother. There's essentially no distinction
between primitives and objects, and no standard objects that are
immutable by default, though I suppose you could use operator
overloading to create monsters. (That's really what happens with java
in String.operator=(), I guess.)
- Gerry Quinn
Oliver Wong
"Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
Perhaps that interpretation is natural to you, but it is not natural to
me. I called the function "manipulateString" because in the original post, I
was showing how Java would behave if it were pass by reference. (The
original post went something like "Since I'm passing by reference, I should
be able to manipulate the string, right? But I can't manipulate the string!
So Java isn't pass by reference!" etc.) It was intentionally mis-named to
illustrate the misunderstanding some people have about passing by reference
versus passing by value.
> The lines:
> stringToManipulate = "DEF";
> and
> objectToManipulate.x = 10;
>
> ..both seem on the surface to be manipulating an object passed for that
> purpose. But in the first case the string is never changed because
> strings are immutable and there is a secret 'new' involved. Which
> means your original explanation was wrong - you never mentioned this.
Because of the topic we're discussing, the terminology has to be very
precise here. Strings are immutable. So are integers. You didn't change the
string. You changed the referenced named "stringToManipulate" to point to a
DIFFERENT string. Whereas it used to point to the string "ABC", it now
points to the string "DEF". The original string "ABC" has not be modified,
as you said.
There is actually no secret "new" involved because of the way Java
optimizes Strings by allocating them once in a static allocator upon class
load and re-uses Strings. Java does treat Strings specially: Since they are
used to frequently in programs, they are one of the most heavily optimized
objects, sometimes "cheating" and having direct hooks into the Java Virtual
Machine to speed up processing. I didn't think this was going to become an
issue, but since it seems to have become so, why don't we switch to using
the Integer class instead? e.g.:
integerToManipulate = new Integer(5);
objectToManipulate.x = 10;
> In the second case there is no secret 'new' because Object is mutable
> and I am allowed change the object to which a reference is passed.
That is not "why" there is no secret "new". The Integer class is
immutable as shown in the new code snippet above, and the "new" there cannot
be made "secret". The secretness or non-secretness of the "new" has nothing
to do with immutability and has to do with virtual machine optimizations.
> Primitives, objects, mutability - I rest my case that Java, if it is to
> be called consistent, is consistent in an excessively complicated
> fashion.
Primitives, objects and mutability are "off topic" with regards to my
original claim, which I'm requoting here:
<quote>
Java has consistent, but non-intuitive, rules involving passing by
value/passing by reference.
</quote>
Note that while I believe that Java is consistent in other areas
(including in the areas of primitives, objects and mutability), that was not
the claim I was trying to debate, so it's somewhat frustrating to see you
steer the conversation in this new direction without addressing the original
claim.
> In C++ there's none of this bother. There's essentially no distinction
> between primitives and objects, and no standard objects that are
> immutable by default, though I suppose you could use operator
> overloading to create monsters. (That's really what happens with java
> in String.operator=(), I guess.)
I can't comment as I haven't used C++ much. I'd like to add though that
an object being immutable is a very highly desired quality in many
scenarios. Objects used as keys in hashtables should be ideally be
immutable, for example.
- Oliver
Gerry Quinn
> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
> > The lines:
> > stringToManipulate = "DEF";
> > and
> > objectToManipulate.x = 10;
> >
> > ..both seem on the surface to be manipulating an object passed for that
> > purpose. But in the first case the string is never changed because
> > strings are immutable and there is a secret 'new' involved. Which
> > means your original explanation was wrong - you never mentioned this.
>
> Because of the topic we're discussing, the terminology has to be very
> precise here. Strings are immutable. So are integers. You didn't change the
> string. You changed the referenced named "stringToManipulate" to point to a
> DIFFERENT string. Whereas it used to point to the string "ABC", it now
> points to the string "DEF". The original string "ABC" has not be modified,
> as you said.
>
> There is actually no secret "new" involved because of the way Java
> optimizes Strings by allocating them once in a static allocator upon class
> load and re-uses Strings.
In other words, a secret 'new', except that it is done on class
loading.
> Java does treat Strings specially: Since they are
> used to frequently in programs, they are one of the most heavily optimized
> objects, sometimes "cheating" and having direct hooks into the Java Virtual
> Machine to speed up processing. I didn't think this was going to become an
> issue, but since it seems to have become so, why don't we switch to using
> the Integer class instead? e.g.:
>
> integerToManipulate = new Integer(5);
> objectToManipulate.x = 10;
The issue doesn't come up here because there is no secret 'new'
involved with the Integer class. You could not have made the case you
were trying to make using Java's inconsistent String class.
> > In the second case there is no secret 'new' because Object is mutable
> > and I am allowed change the object to which a reference is passed.
>
> That is not "why" there is no secret "new". The Integer class is
> immutable as shown in the new code snippet above, and the "new" there cannot
> be made "secret". The secretness or non-secretness of the "new" has nothing
> to do with immutability and has to do with virtual machine optimizations.
The 'new' is there because of immutability. It is secret because of
Java's inconsistency.
> > Primitives, objects, mutability - I rest my case that Java, if it is to
> > be called consistent, is consistent in an excessively complicated
> > fashion.
>
> Primitives, objects and mutability are "off topic" with regards to my
> original claim, which I'm requoting here:
>
> <quote>
> Java has consistent, but non-intuitive, rules involving passing by
> value/passing by reference.
> </quote>
>
> Note that while I believe that Java is consistent in other areas
> (including in the areas of primitives, objects and mutability), that was not
> the claim I was trying to debate, so it's somewhat frustrating to see you
> steer the conversation in this new direction without addressing the original
> claim.
I steered it in that direction because you made incorrect claims to
which they are relevant. You used String rather than Integer because
the 'new' is secret. If the 'new' were explicit, arguments such as:
QUOTE:
<< On the second line, the value of the reference is passed along, not
the address, so the second method receives "54" and not "3". Therefore,
it cannot ever actually modify the contents of memory location 3, and
therefore it cannot ever change what object the "myString" reference
points to. >>
..implying that the contents of address 54 could be altered, would be
obviously meaningless.
- Gerry Quinn
Oliver Wong
"Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
>> precise here. Strings are immutable. So are integers. You didn't change
>> the
>> string. You changed the referenced named "stringToManipulate" to point to
>> a
>> DIFFERENT string. Whereas it used to point to the string "ABC", it now
>> points to the string "DEF". The original string "ABC" has not be
>> modified,
>> as you said.
>>
>> There is actually no secret "new" involved because of the way Java
>> optimizes Strings by allocating them once in a static allocator upon
>> class
>> load and re-uses Strings.
>
> In other words, a secret 'new', except that it is done on class
> loading.
Like I said, we're starting to nitpick here, so I'd like for the
terminology to be very precise. To call what happens in class loading a
'new' operation is misleading. I'm willing to let this simplifying
assumption slide for now, and say "Okay, fine, if you want to call it a
'secret new', then go ahead", but if you later on use this as an argument
for Java's pass by value system being inconsistent, I'll have to retract
that statement and start talking about what really happens at class loading.
>
>> Java does treat Strings specially: Since they are
>> used to frequently in programs, they are one of the most heavily
>> optimized
>> objects, sometimes "cheating" and having direct hooks into the Java
>> Virtual
>> Machine to speed up processing. I didn't think this was going to become
>> an
>> issue, but since it seems to have become so, why don't we switch to using
>> the Integer class instead? e.g.:
>>
>> integerToManipulate = new Integer(5);
>> objectToManipulate.x = 10;
>
> The issue doesn't come up here because there is no secret 'new'
> involved with the Integer class. You could not have made the case you
> were trying to make using Java's inconsistent String class.
The case I was trying to make is that Java always passes by value.
Whether or not a "new" is involved (nevermind whether that new is "secret"
or not) seems to be irrelevant to me (whether a new object is created, or
the same object is used, method calls still use pass by value), but since
this is the point you want to get addressed, I'm addressing it.
>
>> > In the second case there is no secret 'new' because Object is mutable
>> > and I am allowed change the object to which a reference is passed.
>>
>> That is not "why" there is no secret "new". The Integer class is
>> immutable as shown in the new code snippet above, and the "new" there
>> cannot
>> be made "secret". The secretness or non-secretness of the "new" has
>> nothing
>> to do with immutability and has to do with virtual machine optimizations.
>
> The 'new' is there because of immutability. It is secret because of
> Java's inconsistency.
That is not *WHY* the "new" is there. You use the "new" keyword for
instantiating a class, regardless of whether the instances of that class are
mutable or not. And to say it (the "new" with regards to Strings) is secret
*BECAUSE* of Java's inconsistency is very misleading. Do you honestly
believe the designers of Java said to themselves "Hmm, since Java is
inconsistent, we'd better make the 'new' secret"? I think it happened more
like "Hmm, it'd be nice if Strings had syntactic sugar so that they could be
treated like primitives instead of Objects."
At the very most, you could take the position of "Java is inconsistent
because Strings have syntactic sugar so that they can be treated like
primitives". Every statement you have made about "secret news" has either
been a result of misunderstanding on your part of how Java Strings work (and
you seem to refuse to accept corrections to your misunderstanding), or just
intentional FUD spreading.
>> Primitives, objects and mutability are "off topic" with regards to my
>> original claim, which I'm requoting here:
>>
>> <quote>
>> Java has consistent, but non-intuitive, rules involving passing by
>> value/passing by reference.
>> </quote>
>>
>> Note that while I believe that Java is consistent in other areas
>> (including in the areas of primitives, objects and mutability), that was
>> not
>> the claim I was trying to debate, so it's somewhat frustrating to see you
>> steer the conversation in this new direction without addressing the
>> original
>> claim.
>
> I steered it in that direction because you made incorrect claims to
> which they are relevant. You used String rather than Integer because
> the 'new' is secret. If the 'new' were explicit, arguments such as:
>
> QUOTE:
> << On the second line, the value of the reference is passed along, not
> the address, so the second method receives "54" and not "3". Therefore,
> it cannot ever actually modify the contents of memory location 3, and
> therefore it cannot ever change what object the "myString" reference
> points to. >>
>
> ..implying that the contents of address 54 could be altered, would be
> obviously meaningless.
Alright, so I made a mistake in choosing a poor example. I still believe
the original claim is accurate though. Will you allow me to give a new
example while maintaining the original claim?
- Oliver
Gerry Quinn
says...
> > I steered it in that direction because you made incorrect claims to
> > which they are relevant. You used String rather than Integer because
> > the 'new' is secret. If the 'new' were explicit, arguments such as:
> >
> > QUOTE:
> > << On the second line, the value of the reference is passed along, not
> > the address, so the second method receives "54" and not "3". Therefore,
> > it cannot ever actually modify the contents of memory location 3, and
> > therefore it cannot ever change what object the "myString" reference
> > points to. >>
> >
> > ..implying that the contents of address 54 could be altered, would be
> > obviously meaningless.
>
> Alright, so I made a mistake in choosing a poor example. I still believe
> the original claim is accurate though. Will you allow me to give a new
> example while maintaining the original claim?
The claim "Java always passes by value" is trivially true but
meaningless. Every ordinary language passes parameters on a stack that
contains things that can be called values.
When you pass a reference, you are "passing by reference", if the term
is to have any meaning at all.
In C++, I can write a function:
void Manipulate( int & val ){}
..which takes a reference. Am I passing by reference? Of course I am!
But it is the "value of the reference", i.e. a pointer to an int, that
goes on the stack. However I can manipulate either the reference or
the referred object, or both:
// Change the value referred to - what normally happens
val = 99;
// Change the value passed, which is of course the reference
// I have to go a slightly long way round as &val is not an l-value
int* pRef = & val;
pRef = (int*)99;
The latter is what you implied was happening in your Java example. Of
course you would never want to be doing anything like this by accident,
though if I return immediately I'll do no harm.
If you had used an object other than a string, the equivalent would
have been:
int* pRef = & val;
pRef = new int( 99 );
Again pointless, though if I return immediately now I'll have a memory
leak, which in your Java example would be garbage collected.
So, whether you can manipulate the reference, or the referred, or both,
surely has no influence on the question of whether you pass by
reference. Saying that Java "passes the value of a reference" is fine,
but saying that it "always passes by value", as if that were some
illustration of its marvellous consistency, just muddies the water,
IMO.
- Gerry Quinn
Chris Dollin
> The claim "Java always passes by value" is trivially true but
> meaningless. Every ordinary language passes parameters on a stack that
> contains things that can be called values.
Whether or not parameters are passed on a stack is an implementation
detail. Indeed, whether or not a language /has/ a stack is an
implementation detail. But you could fix up that part of your claim.
> When you pass a reference, you are "passing by reference", if the term
> is to have any meaning at all.
I don't see it that way. "Pass by reference" has a specific, historical
meaning: an argument passed by reference can be updated in the callee
and have the change visible in the caller. In particular, consider the
case where the actual argument is a variable, as in this piece of
Pascal:
procedure example( var x: integer ) begin x := x + 1 end;
var z: integer;
begin z := 0; example( z ); writeln( z ) end
z is passed by reference, not by value; updates to x within example
are reflected in the value of the actual argument. Pascal has
/both/ means of argument passing - by reference, and by value; the
distinction is applied through the parameter declaration.
In Pascal there are no "references" you can pass around - they're not
values in the language. (Pascal has pointers, but those are different
things.) The parameter-passing machinery can do things you can't
do otherwise.
Consider also Algol 68, where references are first-class values. Just
because you pass a reference as an argument doesn't mean you're
passing "by reference", ie in order to write back through the reference
into the variable (although Algol 68 conflates the notion of "variable"
and "reference", which I think is an understandable and elegant design
error).
> In C++, I can write a function:
>
> void Manipulate( int & val ){}
>
> ..which takes a reference. Am I passing by reference? Of course I am!
> But it is the "value of the reference", i.e. a pointer to an int, that
> goes on the stack. However I can manipulate either the reference or
> the referred object, or both:
>
> // Change the value referred to - what normally happens
> val = 99;
>
> // Change the value passed, which is of course the reference
> // I have to go a slightly long way round as &val is not an l-value
> int* pRef = & val;
> pRef = (int*)99;
I don't think that's what you meant: `(int *) 99` tries to cast an
integer value to a pointer, which is a deeply suspicious thing to
be doing for this kind of example.
> So, whether you can manipulate the reference, or the referred, or both,
> surely has no influence on the question of whether you pass by
> reference.
It looks to me more like the heart of the matter.
> Saying that Java "passes the value of a reference" is fine,
> but saying that it "always passes by value", as if that were some
> illustration of its marvellous consistency, just muddies the water,
> IMO.
No; it expresses that parameter-passing does not introduce /additional/
references. The only references that arrive in the called method were
there in the argument list to start with - where they were values of
the language, just as 17, '!', and 98.4 are.
--
Chris "one-track" Dollin
Capability does not imply necessity.
Oliver Wong
"Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
[SNIP]
>
> The claim "Java always passes by value" is trivially true but
> meaningless. Every ordinary language passes parameters on a stack that
> contains things that can be called values.
>
> When you pass a reference, you are "passing by reference", if the term
> is to have any meaning at all.
>
> In C++, I can write a function:
>
> void Manipulate( int & val ){}
>
> ..which takes a reference. Am I passing by reference? Of course I am!
> But it is the "value of the reference", i.e. a pointer to an int, that
> goes on the stack. However I can manipulate either the reference or
> the referred object, or both:
This is it. This is the key. In Java, you can NEVER manipulate the
original reference[*]. You can ONLY manipulate the referred object. That's
what I meant by Java always passes by value. C++, as you have shown, differs
in this respect.
- Oliver
[*] I say "original" reference because there are two references here: The
reference that exists in the calling code, and the reference that exists in
the called code.
Arthur J. O'Dwyer
On Thu, 10 Nov 2005, Oliver Wong wrote:
> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote...
>>
>> The claim "Java always passes by value" is trivially true but
>> meaningless. Every ordinary language passes parameters on a stack that
>> contains things that can be called values.
>>
>> When you pass a reference, you are "passing by reference", if the term
>> is to have any meaning at all.
>>
>> In C++, I can write a function:
>>
>> void Manipulate( int & val ){}
>>
>> ..which takes a reference. Am I passing by reference? Of course I am!
>> But it is the "value of the reference", i.e. a pointer to an int, that
>> goes on the stack. However I can manipulate either the reference or
>> the referred object, or both:
>
> This is it. This is the key. In Java, you can NEVER manipulate the
> original reference[*]. You can ONLY manipulate the referred object. That's
> what I meant by Java always passes by value. C++, as you have shown, differs
> in this respect.
Not true. In fact, not only can't you change the value of the
"original reference" in C++ (whatever that means), you can't even change
the value of the local parameter --- it's fixed, so that
void Manipulate( int & val )
{
&val = FOO; /* try to manipulate the reference */
}
isn't even valid syntax!
The difference in Java is that all of the ampersands are invisible, and
the 'val = FOO;' line silently succeeds, but does something quite
different from 'val = FOO;' in C++.
I (mostly) agree with Gerry: Java's pointer model is inconsistent,
because some things (ints, doubles) behave one way, and some things
(objects) behave another. And apparently some things (Strings) behave
a third way; I hadn't known that before.
Certainly it's not sensible to say Java "passes by value," except
for ints, doubles, and other primitive types. Objects in Java are passed
by reference, but with unintuitive semantics with respect to assignment.
-Arthur
Oliver Wong
"Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.60-041....@unix47.andrew.cmu.edu...
I'm not very familiar with C++, so I can't comment on the the above,
except to say that it seems to me that Gerry Quinn posted up C++ code that
does something (I'm calling it "pass by reference"), which you cannot do in
Java. Here's my understanding of the semantics of C++. Maybe it's wrong:
<C++ code?>
void function1() {
int i = 5;
function2(&i);
cout << i;
}
void function2(int &i) {
&i = 10;
}
</C++ code?>
My understanding of the way C++ works is that when running function1(),
the output to standard out would be "10". I'm saying you can't do this in
Java. You might complain that I'm using primitives here, so the rules are
somehow different or something, but that's not so. The same is true for
objects:
<Java code>
class MyObject {
private int myValue;
/*This is a constructor.*/
public MyObject(int value) {
this.myValue = value;
}
public int getValue() {
return this.myValue;
}
}
void function1() {
MyObject i = new Object(5);
function2(i);
System.out.println(i.getValue());
}
void function2(MyObject i) {
i = new Object(10);
}
</Java code>
Here, the output will again be "5" and not "10". I don't know if you'll
call the "new" in function2 cheating, but in Java, you pretty much need to
use the new keyword to create a new instance of an object (this isn't
absolutely true, there are ways using reflection to create objects without
using the new keyword, but I think these details are irrelevant to the
discussion). In fact, short of using reflection, there is nothing function2
can do to change the fact that function1 is going to print out 5.
> I (mostly) agree with Gerry: Java's pointer model is inconsistent,
> because some things (ints, doubles) behave one way, and some things
> (objects) behave another. And apparently some things (Strings) behave
> a third way; I hadn't known that before.
Strings DO behave differently from other types of objects which behave
differently from primitives. It would be quite a useless class library if
every object in it behaved in exactly the same way! But the way in which
they are passed between method calls follows the exact same rule: everything
(whether it be a primitive or a reference to an object) is passed by value.
> Certainly it's not sensible to say Java "passes by value," except
> for ints, doubles, and other primitive types. Objects in Java are passed
> by reference, but with unintuitive semantics with respect to assignment.
You lost me here. I thought primitive types in particular behave in the
way that C++ programmers would readily call "pass by value".
I'm starting to realize we have a terminology problem here. There are 4
ways I can see Objects being passed from one method to another:
1) The objects themselves are passed by value.
2) The objects themselves are passed by reference.
3) The reference to the objects are passed by value.
4) The reference to the objects are passed by reference.
Add to this, 2 ways in which primitive types can be passed from one
method to another:
5) The value of the primitive is passed (I call this "pass by value".)
6) A reference to the primitive is passed (I call this "pass by
reference".)
I think we are in agreement with the terminology for passing primitives.
I believe that 2 and 3 are essentially indistinguishable in their end
result. I claim that Java does 3 and 5, both of which I call "passing by
value". You claim that Java does 2 and 5, thus sometimes passing by
reference, sometimes passing by value.
In the end, I think we are in agreement with what Java does, but we are
in disagreement as to what to call it.
Am I correct in this belief?
- Oliver
Arthur J. O'Dwyer
(It might help to read the last part of this first.)
On Thu, 10 Nov 2005, Oliver Wong wrote:
>
> "Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote...
>> On Thu, 10 Nov 2005, Oliver Wong wrote:
>>> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote...
>>>>
>>>> The claim "Java always passes by value" is trivially true but
>>>> meaningless. Every ordinary language passes parameters on a stack that
>>>> contains things that can be called values.
>>>>
>>>> When you pass a reference, you are "passing by reference", if the term
>>>> is to have any meaning at all.
[...]
> I'm not very familiar with C++, so I can't comment on the the above,
> except to say that it seems to me that Gerry Quinn posted up C++ code that
> does something (I'm calling it "pass by reference"), which you cannot do in
> Java. Here's my understanding of the semantics of C++. Maybe it's wrong:
>
> <C++ code?>
> void function1() {
> int i = 5;
> function2(&i);
> cout << i;
> }
>
> void function2(int &i) {
> &i = 10;
The above line has invalid syntax --- it should be 'i = 10;'. This does
indeed modify the value of 'i' back in 'function1', as well as in
'function2' --- because both names refer to the same object.
> }
> </C++ code?>
[... the Java "equivalent"]
> void function2(MyObject i) {
> i = new Object(10);
> }
> </Java code>
>
> Here, the output will again be "5" and not "10".
Right. This is because Java's object model treats assignment differently
from other operations. If you did the logical thing and modified the
"value" of 'i' like this:
i.myValue = 10; /* pretend 'myValue' is public in this example */
then you'd see the change back in 'function1', because 'i' /is/ passed
by reference --- the function call 'function2(i)' passes a reference to
the object named 'i', rather than its value.
But Java's object model is unintuitive: the assignment 'i.myValue=10'
changes the original object, but the assignment 'i=new Object(10)'
actually changes the target of the reference passed to 'function2'.
C++ disallows changing references in this way --- quite sensibly, I
think!
> In fact, short of using reflection, there is nothing function2
> can do to change the fact that function1 is going to print out 5.
Yes, I believe we all agree on that point. It's just that I claim
that that fact is counterintuitive and indicative of bad language design,
while you claim it's consistent and (presumably) indicative of good
language design.
>> I (mostly) agree with Gerry: Java's pointer model is inconsistent,
>> because some things (ints, doubles) behave one way, and some things
>> (objects) behave another. And apparently some things (Strings) behave
>> a third way; I hadn't known that before.
>
> Strings DO behave differently from other types of objects which behave
> differently from primitives. It would be quite a useless class library if
> every object in it behaved in exactly the same way! But the way in which
> they are passed between method calls follows the exact same rule: everything
> (whether it be a primitive or a reference to an object) is passed by value.
I must have misunderstood what Gerry said earlier, then.
>> Certainly it's not sensible to say Java "passes by value," except
>> for ints, doubles, and other primitive types. Objects in Java are passed
>> by reference, but with unintuitive semantics with respect to assignment.
>
> You lost me here. I thought primitive types in particular behave in the
> way that C++ programmers would readily call "pass by value".
Yes. Java passes primitive types by value, and objects by reference.
That is, 'f(i)' passes a new copy of the value of 'i' if 'i' is a
primitive, but it passes a reference to 'i' itself if 'i' is an object.
> I'm starting to realize we have a terminology problem here. There are 4
> ways I can see Objects being passed from one method to another:
>
> 1) The objects themselves are passed by value.
> 2) The objects themselves are passed by reference.
> 3) The reference to the objects are passed by value.
> 4) The reference to the objects are passed by reference.
>
> Add to this, 2 ways in which primitive types can be passed from one
> method to another:
>
> 5) The value of the primitive is passed (I call this "pass by value".)
> 6) A reference to the primitive is passed (I call this "pass by
> reference".)
>
> I think we are in agreement with the terminology for passing primitives.
>
> I believe that 2 and 3 are essentially indistinguishable in their end
> result. I claim that Java does 3 and 5, both of which I call "passing by
> value". You claim that Java does 2 and 5, thus sometimes passing by
> reference, sometimes passing by value.
Okay, using this terminology, I agree that Java does 3 and 5, but since
3 involves silently passing a reference, I call it "pass-by-reference."
Therefore Java sometimes passes by reference, and sometimes by value.
The "weirdness" of Java's handling of assignment comes from the fact
that it does 3 and not 2. C++ does 2, so that
foo.value = 42;
and
foo = 42;
behave the same way (both modify the original 'foo' in some way). Java
does 3, so that the two lines produce radically different effects.
I call this a bad thing.
-Arthur
Jon Harrop
> <C++ code?>
> void function1() {
> int i = 5;
> function2(&i);
> cout << i;
> }
>
> void function2(int &i) {
> &i = 10;
> }
> </C++ code?>
I think you mean:
void function1() {
int i = 5;
function2(i);
cout << i;
}
void function2(int &i) {
i = 10;
}
which will print "10". The single & denotes pass by reference.
Oliver Wong
"Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.60-041....@unix41.andrew.cmu.edu...
Okay, I think I see a new way in which our views differ; consider the
following statement:
x = y;
Now there isn't enough information here to know where x is a variable
containing a primitive, or if it is a reference pointing to an Object. But
to me, the operation being performed in both cases is the same: Whatever
value that is stored in x is being modified.
If x is a primitive integer, for example, then after the assignment, x
will contain a new primitive integer (or possibly to the same integer if x
== y). I.e., I say that "the value of x has changed."
On the other hand, if x is a reference, then x is pointing to some
object, and after this assignment, x is pointing to a new object (or
possibly the same object if x == y). I still say that the value of x has
changed. It's not the object that x was pointing to that changed, but x, the
reference itself, which has changed.
Now consider the following statement:
x.y = z;
Here, I know that x is not a primitive type, because it is on the left
side of the dot operator. However, I do not know whether y is a variable
containing a primitive type or a reference to an object.
It is not correct to say that "x" has changed. Rather, the *OBJECT* that
x is pointing to has changed, but x itself still has the same value (i.e.
the address in RAM of the location of the object).
[snip]
> Yes. Java passes primitive types by value, and objects by reference.
> That is, 'f(i)' passes a new copy of the value of 'i' if 'i' is a
> primitive, but it passes a reference to 'i' itself if 'i' is an object.
This is a terminology issue again, I think. In the latter case, I do not
say "it passes a reference to 'i' itself if 'i' is an object". Rather, I say
that 'i' IS the reference, and it is getting passed. I.e. 'i' is NOT an
Object, but rather a reference to an object. And it's value is getting
passed.
I believe C++ allows you to get the address of just about anything, thus
allowing you to create a reference to anything you wanted to. For example,
you could have a reference to a primitive in C++, while you cannot do this
in Java. In particular, you could take a reference, and then get a reference
to it (I believe the C++ people call this "a pointer to a pointer"). No such
thing exists in Java.
So given this clarification, let me re-quote something you wrote:
> Right. This is because Java's object model treats assignment differently
> from other operations. If you did the logical thing and modified the
> "value" of 'i' like this:
>
> i.myValue = 10; /* pretend 'myValue' is public in this example */
>
> then you'd see the change back in 'function1', because 'i' /is/ passed
> by reference --- the function call 'function2(i)' passes a reference to
> the object named 'i', rather than its value.
In the "Java view" of the world, it 'i' is not the object; rather, it is
a reference to the object. 'i' itself has not changed. It is the object that
'i' pointed to which changed. Since the 'i' in function1 and the 'i' in
function2 both pointed to the same object, it's true that when function2
modifies the object, function1 will see it. But if function2 tries to modify
the reference itself, function1 will not see any such changes. That is
because the reference was passed by value. The reference was not passed by
reference. There is no pointer to a pointer in Java.
>> I'm starting to realize we have a terminology problem here. There are
>> 4
>> ways I can see Objects being passed from one method to another:
>>
>> 1) The objects themselves are passed by value.
>> 2) The objects themselves are passed by reference.
>> 3) The reference to the objects are passed by value.
>> 4) The reference to the objects are passed by reference.
>>
>> Add to this, 2 ways in which primitive types can be passed from one
>> method to another:
>>
>> 5) The value of the primitive is passed (I call this "pass by value".)
>> 6) A reference to the primitive is passed (I call this "pass by
>> reference".)
>>
[snip]
>
> The "weirdness" of Java's handling of assignment comes from the fact
> that it does 3 and not 2. C++ does 2, so that
>
> foo.value = 42;
> and
> foo = 42;
>
> behave the same way (both modify the original 'foo' in some way). Java
> does 3, so that the two lines produce radically different effects.
> I call this a bad thing.
To me, the C++ way is "weird" in that the top line, "foo.value = 42"
should be modifying "value", not "foo".
- Oliver
Jon Harrop
> I believe C++ allows you to get the address of just about anything,
> thus
> allowing you to create a reference to anything you wanted to. For example,
> you could have a reference to a primitive in C++, while you cannot do this
> in Java. In particular, you could take a reference, and then get a
> reference to it (I believe the C++ people call this "a pointer to a
> pointer"). No such thing exists in Java.
"Pointer" != "reference" in C++. You can have a pointer to a pointer but
that is not the same as a reference to a reference.
> To me, the C++ way is "weird" in that the top line, "foo.value = 42"
> should be modifying "value", not "foo".
Both C++ and Java are weird. Remarkably, both languages impose unnecessary
requirements on what you can handle by reference.
Gerry Quinn
> Gerry Quinn wrote:
=
> > // Change the value passed, which is of course the reference
> > // I have to go a slightly long way round as &val is not an l-value
> > int* pRef = & val;
> > pRef = (int*)99;
>
> I don't think that's what you meant: `(int *) 99` tries to cast an
> integer value to a pointer, which is a deeply suspicious thing to
> be doing for this kind of example.
It is what I meant (I just wanted a value, any value), but it's wrong
anyway. I still don't get to change the value of &val, whatever I do.
pVal starts with the same value as &val, and I can either leave it as
it is (in which case *pVal is the same as val) or change it (in which
case it points somewhere else, and *pVal is as if I could have changed
&val), but that's not quite the same thing as changing &val itself.
- Gerry Quinn
Gerry Quinn
says...
>
> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
> news:MPG.1ddd5272d...@news.indigo.ie...
> [SNIP]
> >
> > The claim "Java always passes by value" is trivially true but
> > meaningless. Every ordinary language passes parameters on a stack that
> > contains things that can be called values.
> >
> > When you pass a reference, you are "passing by reference", if the term
> > is to have any meaning at all.
> >
> > In C++, I can write a function:
> >
> > void Manipulate( int & val ){}
> >
> > ..which takes a reference. Am I passing by reference? Of course I am!
> > But it is the "value of the reference", i.e. a pointer to an int, that
> > goes on the stack. However I can manipulate either the reference or
> > the referred object, or both:
>
> This is it. This is the key. In Java, you can NEVER manipulate the
> original reference[*]. You can ONLY manipulate the referred object. That's
> what I meant by Java always passes by value. C++, as you have shown, differs
> in this respect.
It turns out that it doesn't. I was wrong, and in C++ I can't change
the value of the reference, though I can create something of the same
value that I can change at will.
So, I think Arthur is hitting the nail when he talks about assignment
to references.
- Gerry Quinn
Gerry Quinn
says...
> news:Pine.LNX.4.60-041....@unix47.andrew.cmu.edu...
> > The difference in Java is that all of the ampersands are invisible, and
> > the 'val = FOO;' line silently succeeds, but does something quite
> > different from 'val = FOO;' in C++.
>
> I'm not very familiar with C++, so I can't comment on the the above,
> except to say that it seems to me that Gerry Quinn posted up C++ code that
> does something (I'm calling it "pass by reference"), which you cannot do in
> Java. Here's my understanding of the semantics of C++. Maybe it's wrong:
No, I was doing somethhing similar in a sense, but I wasn't changing
the reference. As Arthur says, you can't. You can get a pointer that
points to the same place, and change that, if you want, which is what I
was doing.
- Gerry Quinn
blm...@myrealbox.com
Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
>In article <qyLaf.74524$y_1.47056@edtnps89>, ow...@castortech.com
>says...
>> "Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
>> news:MPG.1dd53c78a...@news.indigo.ie...
>
>> So consider this short Java code snippet:
>>
>> <code>
>> public static void main() {
>> String myString = "String A";
>> manipulateString(myString);
>> System.out.println(myString);
>> }
>>
>> public static void manipulateString(String stringToManipulate) {
>> stringToManipulate = "String B";
>> }
>> </code>
>
>> What actually happens in Java though is "String A" gets printed out.
>> Why? Because Java is "pass by value".
>>
>> On the second line, the value of the reference is passed along, not the
>> address, so the second method receives "54" and not "3". Therefore, it
>> cannot ever actually modify the contents of memory location 3, and therefore
>> it cannot ever change what object the "myString" reference points to.
>
>This isn't what happens. The reasons strings in Java act as above is
>because they are yet another category, immutable objects, that get
>copied invisibly. The function gets the address of yet another copy of
>the string, and performs a therefore useless manipulation of it.
Nonsense. Why would you think this invisible copying is happening?
Immutability of objects is, AFAIK, implemented simply by not providing
any methods for changing their state. If a class doesn't provide any
methods for changing the state of its objects, objects of that class
are immutable.
What's actually happening is that the main method has a variable
myString *which is a reference to a String object*, and this variable
can be passed -- by value -- to other methods. The only copying here
is of the reference. In your example, the parameter stringToManipulate
in method manipulateString contains a copy .... not of a String object,
but of *a reference to a String object*. Since this reference points
to the same object pointed to by the caller's reference, if the String
class provided any methods for changing a String object's values,
manipulateString could call them and change .... not the caller's
myString, *but the object pointed to by myString*.
Exactly the same thing would be happening if instead of String objects
we were using objects of some class that is not immutable.
There are only a few ways in which String objects are special, and
none of them seem relevant here:
(*) One can create String objects without an explicit new, e.g.,
String hello = "hello";
rather than
String hello = new String("hello");
(*) "+" is overloaded for the String class (to mean concatenation),
but not for other classes.
(*) The runtime system attempts to optimize things a bit by not
creating unneeded String objects. For example, if you write
String hello = "hello";
String helloAgain = "hello";
the runtime system will create only one String object, with two
*references to it* (hello and helloAgain). This is safe to do because
Strings are immutable.
[ snip ]
I have more to say in this thread but will continue in another post,
since others have said parts of what I have in mind to say ....
But notice again the phrases I put *in asterisks* above ....
--
| B. L. Massingill
| ObDisclaimer: I don't speak for my employers; they return the favor.
blm...@myrealbox.com
I claim that how Java treats non-primitive variables is only
"unintuitive" if (1) you are a C programmer, or (2) you learned
Java from a source that was not precise about terminology.
In C++, if I have a class MyObject and write
MyObject i;
then i is *an instance of the class MyObject*, is it not?
while if I write the same line in Java, i is *a reference that
can point to an instance of MyObject*. No instances of MyObject
are created unless/until one writes something such as
i = new MyObject();
(ignoring for now the ways in which you can create objects with
"reflection", e.g., newInstance() in class Class).
In C++, you could (I believe -- my C++ is more than a little rusty)
get the same effect by writing
MyObject * i;
So, when in Java one writes
i.myValue = 10;
the nearest C++ equivalent is not
i.myValue = 10; (where i is a myObject)
but
i->myValue 10; (where is a pointer to a myObject)
Similarly, when in Java one writes
MyObject i;
MyObject j = new MyObject();
i = j;
the effect is to create one MyObject object, with two references
to it. If you wrote this is C++, exactly what would happen would
depend on whether MyObject had overloaded the "=" operator and how.
Now *that* is a potential source of confusion, IMO, though it does
provide some flexibility Java lacks. To get the same effect as
the above lines in Java, in C++, you would write
MyObject *i;
MyObject *j = new MyObject();
i = j;
(Or so I think -- rusty C++, as I said.)
Anyway. So if you are a C++ programmer, I can understand why
the way things work in Java might seem odd and unintuitive.
People who come to Java without a background in C++ to possibly
lead them astray .... I think some confusion may result from
the fact that people are apt to say that the variable i above
"is a MyObject", when it would be more correct to say that i
"is a reference to a MyObject".
The distinction is, IMO, critical. Once you start viewing Java in
terms of "all variables of non-primitive types are *references to
objects* (not objects themselves)", then everything starts to seem
consistent and reasonable. Well, that was my experience anyway.
I guess YMMV.
>
>> In fact, short of using reflection, there is nothing function2
>> can do to change the fact that function1 is going to print out 5.
>
> Yes, I believe we all agree on that point. It's just that I claim
>that that fact is counterintuitive and indicative of bad language design,
>while you claim it's consistent and (presumably) indicative of good
>language design.
>
Another vote here for "consistent, once you understand how things
work".
As for "counterintuitive" -- I would claim that what "intuitive"
means depends on a lot on one's background. GUIs are said to be
very intuitive, but I still remember how baffling I found Windows
at first, after many years working in mostly-CLI environments.
Eventually I sorted out enough of the basic ideas to get past some
of my initial misconceptions, but it took some, um, interesting
learning experiences.
>
>>> I (mostly) agree with Gerry: Java's pointer model is inconsistent,
>>> because some things (ints, doubles) behave one way, and some things
>>> (objects) behave another. And apparently some things (Strings) behave
>>> a third way; I hadn't known that before.
>>
>> Strings DO behave differently from other types of objects which behave
>> differently from primitives. It would be quite a useless class library if
>> every object in it behaved in exactly the same way! But the way in which
>> they are passed between method calls follows the exact same rule: everything
>> (whether it be a primitive or a reference to an object) is passed by value.
>
> I must have misunderstood what Gerry said earlier, then.
>
It's possible, too, that Gerry was confused. I think he's wrong
about under-the-hood copying when one passes immutable objects,
for example.
>
>
>>> Certainly it's not sensible to say Java "passes by value," except
>>> for ints, doubles, and other primitive types. Objects in Java are passed
>>> by reference, but with unintuitive semantics with respect to assignment.
>>
>> You lost me here. I thought primitive types in particular behave in the
>> way that C++ programmers would readily call "pass by value".
>
> Yes. Java passes primitive types by value, and objects by reference.
>That is, 'f(i)' passes a new copy of the value of 'i' if 'i' is a
>primitive, but it passes a reference to 'i' itself if 'i' is an object.
>
Well -- no. Java has no ability to pass objects at all. What it
does have is the ability to pass *references to objects*. So f(i)
passes a new copy of i -- whether i is a primitive type or a reference
type. "What if i is neither one? What if it's an object?" AFAIK,
not possible in Java. This may be the critical point.
>
>> I'm starting to realize we have a terminology problem here. There are 4
>> ways I can see Objects being passed from one method to another:
>>
>> 1) The objects themselves are passed by value.
>> 2) The objects themselves are passed by reference.
>> 3) The reference to the objects are passed by value.
>> 4) The reference to the objects are passed by reference.
>>
>> Add to this, 2 ways in which primitive types can be passed from one
>> method to another:
>>
>> 5) The value of the primitive is passed (I call this "pass by value".)
>> 6) A reference to the primitive is passed (I call this "pass by
>> reference".)
>>
>> I think we are in agreement with the terminology for passing primitives.
>>
>> I believe that 2 and 3 are essentially indistinguishable in their end
>> result. I claim that Java does 3 and 5, both of which I call "passing by
>> value". You claim that Java does 2 and 5, thus sometimes passing by
>> reference, sometimes passing by value.
>
> Okay, using this terminology, I agree that Java does 3 and 5, but since
>3 involves silently passing a reference, I call it "pass-by-reference."
>Therefore Java sometimes passes by reference, and sometimes by value.
Only if you think a variable in Java can be an object. But it can't.
>
> The "weirdness" of Java's handling of assignment comes from the fact
>that it does 3 and not 2. C++ does 2, so that
>
> foo.value = 42;
>and
> foo = 42;
>
>behave the same way (both modify the original 'foo' in some way). Java
>does 3, so that the two lines produce radically different effects.
>I call this a bad thing.
>
Only if you think C++ and Java should behave the same way.
C++ allows variables to *be* objects, and to *point to* objects.
Java only allows variables to *point to* objects, and it calls
such variables "references" rather than "pointers", perhaps so
people understand that they aren't exactly like C/C++ pointers.
But in some respects they're similar, since in both cases there's
a distinction between the pointer (reference) and the object it
points to.
Maybe it would have been clearer if Java referenced fields and
methods with the "->" operator rather than the "." operator, since
then I think things might be less confusing for C++ programmers.
Maybe if the designers of Java had foreseen this confusion ....?
Or maybe not. <shrug>
Gerry Quinn
says...
In at least one sense there is an invisible copy happening, i.e. there
is a string "String B" created at class loading.
But this was all thrashed out on the thread already anyway.
- Gerry Quinn
Oliver Wong
"Gerry Quinn" <ger...@DELETETHISindigo.ie> wrote in message
>
> In at least one sense there is an invisible copy happening, i.e. there
> is a string "String B" created at class loading.
Sure, if you define an "invisible copy" as the act of creating a new
string out of nothing. But I think most people assume that for a copy to
occur, there must have been some original string that got copied. I.e., it
implies you started with one String, and then after the copy occurs, you
have two.
What happens at class loading is that you had zero strings, and then you
have one string. I think most people would call that "loading" or
"allocating" or "creation" or something like that; but not "copying".
- Oliver
blm...@myrealbox.com
I can believe that a string "String B" is created when the class is
loaded; that seems like a sensible (inevitable?) way to deal with
something that appears as a constant in the code.
I have no idea why you call this "an invisible copy". Do you think
there are multiple String objects with the value "String B"? If so,
why? If not, why are you talking about invisible copying?
>But this was all thrashed out on the thread already anyway.
I guess those posts didn't make it to my news server? I just looked
again through my saved copy and am still not finding any discussion of
this specific claim (that String objects are invisibly copied).
However, we can drop it, since no one else seems interested, and --
big surprise -- I think the discussion has ended with neither side
having convinced the other.
blm...@myrealbox.com
Once again I notice that I should have read *all* the posts before
replying, since you've made the point I made (in my reply to Gerry),
better. Sorry about the duplication ....
Gerry Quinn
says...
> >In at least one sense there is an invisible copy happening, i.e. there
> >is a string "String B" created at class loading.
>
> I can believe that a string "String B" is created when the class is
> loaded; that seems like a sensible (inevitable?) way to deal with
> something that appears as a constant in the code.
It's only sensible and inevitable when you know about Java's deceptive
string syntax. On the face of it, you are using the constant in the
code directly.
> I have no idea why you call this "an invisible copy". Do you think
> there are multiple String objects with the value "String B"? If so,
> why? If not, why are you talking about invisible copying?
There is an existing one. There is no visible one.
- Gerry Quinn
blm...@myrealbox.com
Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
>In article <3tvht4F...@individual.net>, blm...@myrealbox.com
>says...
>> In article <MPG.1de3d2943...@news.indigo.ie>,
>> Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
>
>> >In at least one sense there is an invisible copy happening, i.e. there
>> >is a string "String B" created at class loading.
>>
>> I can believe that a string "String B" is created when the class is
>> loaded; that seems like a sensible (inevitable?) way to deal with
>> something that appears as a constant in the code.
>
>It's only sensible and inevitable when you know about Java's deceptive
>string syntax. On the face of it, you are using the constant in the
>code directly.
>
>> I have no idea why you call this "an invisible copy". Do you think
>> there are multiple String objects with the value "String B"? If so,
>> why? If not, why are you talking about invisible copying?
>
>There is an existing one. There is no visible one.
>
I'm not following you very well, and we seem to have drifted away
from what I was originally asking about. So, let me try again:
First, with regard to the above post: What is it you think is
deceptive about the syntax? Is it the fact that character
strings are instances of a String class, instead of being ....
what would you find more sensible and/or less deceptive?
Second, with regard to the post to which I originally replied:
Are you claiming only that Java does implicit copying of string
constants at class-loading time (which seems plausible, assuming
that the actual characters are stored in the byte code somewhere
and copied into a String object at class-loading time)? Or are
you claiming (and this is what I assumed your earlier post to
mean) that every time a reference to a String object is passed
to a function/method, the String object is implicitly copied?
Oliver Wong
news:3u1ag9F...@individual.net...
>
> First, with regard to the above post: What is it you think is
> deceptive about the syntax? Is it the fact that character
> strings are instances of a String class, instead of being ....
> what would you find more sensible and/or less deceptive?
I must admit that Sun's syntactic sugar for Strings can be displeasing
to the OO purist. The two alternatives that immediately come to mind is
making strings are primitive type instead of an Object type (I believe this
is what C# has done), or eliminating all primitive types and only have
objects (which I think Sun is moving towards, ever so slowly due to
backwards compatibility requirements, with its introduction of autoboxing
and unboxing).
I'd personally prefer the latter (no primitive types) to the former
(make String primitive). Then we'd only have references and we could avoid
the whole "pass by value/pass by reference" argument (i.e. EVERYTHING is a
reference... and they're passed... by value.) ;)
- Oliver
blm...@myrealbox.com
Oliver Wong <ow...@castortech.com> wrote:
><blm...@myrealbox.com> wrote in message
>news:3u1ag9F...@individual.net...
>>
>> First, with regard to the above post: What is it you think is
>> deceptive about the syntax? Is it the fact that character
>> strings are instances of a String class, instead of being ....
>> what would you find more sensible and/or less deceptive?
>
> I must admit that Sun's syntactic sugar for Strings can be displeasing
>to the OO purist. The two alternatives that immediately come to mind is
>making strings are primitive type instead of an Object type (I believe this
>is what C# has done), or eliminating all primitive types and only have
>objects (which I think Sun is moving towards, ever so slowly due to
>backwards compatibility requirements, with its introduction of autoboxing
>and unboxing).
Hm! I didn't figure to hear opinions from anyone but Mr. Quinn, from
whom I wanted to hear more about why he calls Java's string syntax
deceptive. However ...
>
> I'd personally prefer the latter (no primitive types) to the former
>(make String primitive). Then we'd only have references and we could avoid
>the whole "pass by value/pass by reference" argument (i.e. EVERYTHING is a
>reference... and they're passed... by value.) ;)
>
This might make the OO purists happier, but somehow I don't think it
would stop the argument. The people who say Java passes objects by
reference .... I think they're not getting something fairly basic
about the language (that non-primitive variables are not objects,
but references to objects), and it's not clear to me that removing
primitives from the language would avoid that confusion.
But one can dream.
Arthur J. O'Dwyer
On Wed, 17 Nov 2005, blm...@myrealbox.com wrote:
> Oliver Wong <ow...@castortech.com> wrote:
>> I'd personally prefer the latter (no primitive types) to the former
>> (make String primitive). Then we'd only have references and we could avoid
>> the whole "pass by value/pass by reference" argument (i.e. EVERYTHING is a
>> reference... and they're passed... by value.) ;)
>
> This might make the OO purists happier, but somehow I don't think it
> would stop the argument. The people who say Java passes objects by
> reference .... I think they're not getting something fairly basic
> about the language (that non-primitive variables are not objects,
> but references to objects), and it's not clear to me that removing
> primitives from the language would avoid that confusion.
Well, at least it would get rid of my objection that Java's object model
is "inconsistent" or "unintuitive." I'd still /prefer/ the C(++) model,
but at least if everything in Java were an Object passed by reference
(or "by-value-but-where-that-value-is-itself-a-reference" ;) it would
be obvious what any code did, once you learned one rule, instead of having
to learn Rule A for objects and Rule B for primitives (and Rules C-Z
telling you which standard identifiers refer to primitives and which to
object types).
Also, it would finally allow Java programmers to write swap functions.
:)
(BTW, I'm assisting in an introductory C course this semester, and I do
find that students who learned Java first have a hard time understanding
explicit pointers. I doubt many people who learn explicit pointer-passing
first find it difficult to grasp Java's syntax, which is basically "delete
all the asterisks from C++.")
-Arthur
blm...@myrealbox.com
>> Oliver Wong <ow...@castortech.com> wrote:
>>> I'd personally prefer the latter (no primitive types) to the former
>>> (make String primitive). Then we'd only have references and we could avoid
>>> the whole "pass by value/pass by reference" argument (i.e. EVERYTHING is a
>>> reference... and they're passed... by value.) ;)
>>
>> This might make the OO purists happier, but somehow I don't think it
>> would stop the argument. The people who say Java passes objects by
>> reference .... I think they're not getting something fairly basic
>> about the language (that non-primitive variables are not objects,
>> but references to objects), and it's not clear to me that removing
>> primitives from the language would avoid that confusion.
>
> Well, at least it would get rid of my objection that Java's object model
>is "inconsistent" or "unintuitive." I'd still /prefer/ the C(++) model,
>but at least if everything in Java were an Object passed by reference
>(or "by-value-but-where-that-value-is-itself-a-reference" ;) it would
>be obvious what any code did, once you learned one rule, instead of having
>to learn Rule A for objects and Rule B for primitives (and Rules C-Z
>telling you which standard identifiers refer to primitives and which to
>object types).
But there really is only one rule, once you understand that
"MyObject x" *is not a MyObject, but a reference to a MyObject*
(where "reference" is to be interpreted as "less dangerous /
less powerful relative of pointer" and not as whatever C++ means
by "reference").
As for which standard identifiers refer to primitives and which to
references (to objects), there's only one rule/convention there too
(lower-case for primitives, starts-with-uppercase for references).
But I'll try to shut up now, since I'm pretty sure those of you
who find Java a mass of confusion aren't going to be swayed by yet
another round of "it's all simple when viewed from the right angle."
> Also, it would finally allow Java programmers to write swap functions.
>:)
Now that *would* be nice. :-)
> (BTW, I'm assisting in an introductory C course this semester, and I do
>find that students who learned Java first have a hard time understanding
>explicit pointers. I doubt many people who learn explicit pointer-passing
>first find it difficult to grasp Java's syntax, which is basically "delete
>all the asterisks from C++.")
>
Well, I don't know. I would claim, with all due respect, that
*you* seem to be having a certain amount of difficulty with --
not Java's syntax, maybe, so much as its semantics? "Delete all
the asterisks from C++" seems to be an oversimplification; e.g.,
"MyObject x" means something different in C++ from what it means
in Java.
Interesting, though, about your experiences teaching C to people
who started with Java. It might be interesting to ask *them*
what they think about this discussion (are the rules for passing
parameters in Java weird and confusing), but the answers might
just demonstrate that they don't understand their first language
very well either.
I'm currently teaching Java to people who mostly started in C
(and are still very much beginners with it as well), and they're
struggling too, though not so much with anything pointer-related
as with .... I think it's the object-oriented mind set. So maybe
any attempt to get one's head around something new takes time
and is difficult. <shrug>
Gerry Quinn
says...
> >> I have no idea why you call this "an invisible copy". Do you think
> >> there are multiple String objects with the value "String B"? If so,
> >> why? If not, why are you talking about invisible copying?
> >
> >There is an existing one. There is no visible one.
> >
> I'm not following you very well, and we seem to have drifted away
> from what I was originally asking about. So, let me try again:
>
> First, with regard to the above post: What is it you think is
> deceptive about the syntax? Is it the fact that character
> strings are instances of a String class, instead of being ....
> what would you find more sensible and/or less deceptive?
The following would be less deceptive:
strRef = new String( "String B" );
If that were necessary (as it would be with other types of objects, the
instantiation of a String with the characters 'String B' would be
visible.
strRef = "String B";
gives the impression that the characters 'String B' are used to alter
an existing string, rather than to create a new string which strRef is
then set to. We don't ever see the explicit creation of this string.
That's why I say it is invisible.
> Second, with regard to the post to which I originally replied:
> Are you claiming only that Java does implicit copying of string
> constants at class-loading time (which seems plausible, assuming
> that the actual characters are stored in the byte code somewhere
> and copied into a String object at class-loading time)? Or are
> you claiming (and this is what I assumed your earlier post to
> mean) that every time a reference to a String object is passed
> to a function/method, the String object is implicitly copied?
I should imagine it must be specified somewhere, and that the former
option is used for efficiency.
- Gerry Quinn
Chris Dollin
> In article <3u1ag9F...@individual.net>, blm...@myrealbox.com
> says...
>> In article <MPG.1de53eb85...@news.indigo.ie>,
>> Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
>
>> >> I have no idea why you call this "an invisible copy". Do you think
>> >> there are multiple String objects with the value "String B"? If so,
>> >> why? If not, why are you talking about invisible copying?
>> >
>> >There is an existing one. There is no visible one.
>> >
>> I'm not following you very well, and we seem to have drifted away
>> from what I was originally asking about. So, let me try again:
>>
>> First, with regard to the above post: What is it you think is
>> deceptive about the syntax? Is it the fact that character
>> strings are instances of a String class, instead of being ....
>> what would you find more sensible and/or less deceptive?
>
> The following would be less deceptive:
>
> strRef = new String( "String B" );
>
> If that were necessary (as it would be with other types of objects, the
> instantiation of a String with the characters 'String B' would be
> visible.
And the semantics would be different.
> strRef = "String B";
>
> gives the impression that the characters 'String B' are used to alter
> an existing string, rather than to create a new string which strRef is
> then set to.
To who does it give this impression?
> We don't ever see the explicit creation of this string.
> That's why I say it is invisible.
You are free to say and think this, but it doesn't seem to me
to be helpful. The string object for "String B" is created,
once, before any executions of that assignment is performed.
(You presumably know this; I'm just making it explicit.)
>> Second, with regard to the post to which I originally replied:
>> Are you claiming only that Java does implicit copying of string
>> constants at class-loading time (which seems plausible, assuming
>> that the actual characters are stored in the byte code somewhere
>> and copied into a String object at class-loading time)? Or are
>> you claiming (and this is what I assumed your earlier post to
>> mean) that every time a reference to a String object is passed
>> to a function/method, the String object is implicitly copied?
>
> I should imagine it must be specified somewhere,
It is. (My copy of the JVM book is at home, and is only 1st
edition, otherwise I would produce a reference.) My recollection
is that string literals are as if interned; that is, all string
literals with the same spelling map to the same single string
object. I may remember to look it up.
> and that the former option is used for efficiency.
As in C, for example, where a string literal isn't reconstructed
every time the execution passes through its use.
--
Chris "another virtual machine" Dollin
missing tests don't fail.
Oliver Wong
"Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.60-041....@unix45.andrew.cmu.edu...
>
> On Wed, 17 Nov 2005, blm...@myrealbox.com wrote:
>> Oliver Wong <ow...@castortech.com> wrote:
>>> I'd personally prefer the latter (no primitive types) to the former
>>> (make String primitive). Then we'd only have references and we could
>>> avoid
>>> the whole "pass by value/pass by reference" argument (i.e. EVERYTHING is
>>> a
>>> reference... and they're passed... by value.) ;)
>>
> Also, it would finally allow Java programmers to write swap functions.
> :)
Well, no... Since it's all passed by value, swapping them in a
particular function won't result in them being seen as swapped in the
calling function.
- Oliver
Arthur J. O'Dwyer
On Thu, 17 Nov 2005, Oliver Wong wrote:
> "Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote...
>>> Oliver Wong <ow...@castortech.com> wrote:
>>>> I'd personally prefer the latter (no primitive types) to the former
>>>> (make String primitive). Then we'd only have references and we could
>>>> avoid the whole "pass by value/pass by reference" argument (i.e.
>>>> EVERYTHING is a reference... and they're passed... by value.) ;)
>
>> :)
>
> Well, no... Since it's all passed by value, swapping them in a
> particular function won't result in them being seen as swapped in the
> calling function.
Well, how do you propose to get the /value/ of an int that's passed by
reference, then? (Remember, what you're calling "pass by value" is what
the rest of the world calls "pass by reference.")
void FantasyJavaCanSwapInts(int really_a_reference, int also_a_reference)
{
int k = new int(VALUE_OF(really_a_reference));
VALUE_OF(really_a_reference) = VALUE_OF(also_a_reference);
VALUE_OF(also_a_reference) = VALUE_OF(k);
return;
}
-Arthur
Oliver Wong
"Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.60-041....@unix41.andrew.cmu.edu...
>
>> "Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote...
>>>> Oliver Wong <ow...@castortech.com> wrote:
>>>>> I'd personally prefer the latter (no primitive types) to the former
>>>>> (make String primitive). Then we'd only have references and we could
>>>>> avoid the whole "pass by value/pass by reference" argument (i.e.
>>>>> EVERYTHING is a reference... and they're passed... by value.) ;)
>>
>>> Also, it would finally allow Java programmers to write swap functions.
>>> :)
>>
>> Well, no... Since it's all passed by value, swapping them in a
>> particular function won't result in them being seen as swapped in the
>> calling function.
>
> Well, how do you propose to get the /value/ of an int that's passed by
> reference, then? (Remember, what you're calling "pass by value" is what
> the rest of the world calls "pass by reference.")
I propose that the term "getting the value of an int" is meaningless in
this new language. Instead of doing so, you can compare Integers, convert
them to Strings, add them together, etc. But what does it mean to "get the
value" of something?
> void FantasyJavaCanSwapInts(int really_a_reference, int
> also_a_reference)
> {
> int k = new int(VALUE_OF(really_a_reference));
> VALUE_OF(really_a_reference) = VALUE_OF(also_a_reference);
> VALUE_OF(also_a_reference) = VALUE_OF(k);
> return;
> }
This presumes the existence of some sort of "VALUE_OF" operator or
function or something. The way I imagined Java-without-primitives, such an
operator would not exist.
- Oliver
blm...@myrealbox.com
Fair enough. (I would say that interpreting the above assignment as
"the characters are used to alter an existing string" is no more
likely than the correct interpretation if one understand that strRef
is not a String but a reference to a String, but YMMV, maybe.)
>
>> Second, with regard to the post to which I originally replied:
>> Are you claiming only that Java does implicit copying of string
>> constants at class-loading time (which seems plausible, assuming
>> that the actual characters are stored in the byte code somewhere
>> and copied into a String object at class-loading time)? Or are
>> you claiming (and this is what I assumed your earlier post to
>> mean) that every time a reference to a String object is passed
>> to a function/method, the String object is implicitly copied?
>
>I should imagine it must be specified somewhere, and that the former
>option is used for efficiency.
>
I'm still not sure you answered the question I really meant to
ask here, so let me make it more explicit: Do you claim that every
time a reference to a String object is passed to a function/method,
the String object is implicitly copied?
--
Oliver Wong
<blm...@myrealbox.com> wrote in message
news:3u44q4F...@individual.net...
> In article <MPG.1de6934c6...@news.indigo.ie>,
> Gerry Quinn <ger...@DELETETHISindigo.ie> wrote:
>>
>> strRef = "String B";
>>
>>gives the impression that the characters 'String B' are used to alter
>>an existing string, rather than to create a new string which strRef is
>>then set to. We don't ever see the explicit creation of this string.
>>That's why I say it is invisible.
>
> Fair enough. (I would say that interpreting the above assignment as
> "the characters are used to alter an existing string" is no more
> likely than the correct interpretation if one understand that strRef
> is not a String but a reference to a String, but YMMV, maybe.)
>
I'd imagine that a novice Java programmer (who was not aware that
special syntactic sugar exists for Strings) would see the above assignment
expression and think that a (primitive) string value was being assigned a
primitive variable.
To me, that does not convey an impression of altering an existing string
anymore than the code:
int x = 3;
x = 5;
implies that the existing "3" is somehow being modified to have the
value 5. The variable x here used to contain 3; not it contains 5. The value
3 itself was never modified.
Similarly, the strRef variable used to contain something (perhaps a
reference to the String "String A"), and now it contains (a reference to)
the String "String B". The String "String A" itself was never modified.
- Oliver
Arthur J. O'Dwyer
On Thu, 17 Nov 2005, Oliver Wong wrote:
> "Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote...
>> On Thu, 17 Nov 2005, Oliver Wong wrote:
>>> "Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote...
>>>>> Oliver Wong <ow...@castortech.com> wrote:
>>>>>> I'd personally prefer the latter (no primitive types) to the former
>>>>>> (make String primitive). Then we'd only have references and we could
>>>>>> avoid the whole "pass by value/pass by reference" argument (i.e.
>>>>>> EVERYTHING is a reference... and they're passed... by value.) ;)
>>>
>>>> Also, it would finally allow Java programmers to write swap functions.
>>>> :)
>>>
>>> Well, no... Since it's all passed by value, swapping them in a
>>> particular function won't result in them being seen as swapped in the
>>> calling function.
>>
>> Well, how do you propose to get the /value/ of an int that's passed by
>> reference, then? (Remember, what you're calling "pass by value" is what
>> the rest of the world calls "pass by reference.")
>
> I propose that the term "getting the value of an int" is meaningless in
> this new language. Instead of doing so, you can compare Integers, convert
> them to Strings, add them together, etc. But what does it mean to "get the
> value" of something?
Ah, I think I see what you mean. I just think it's a dumb idea for a
language. ;) You mean we have these sort of "atomic" Integer objects,
with no discernible internal structure, such that we can write
Integer i = new Integer("42"); /* or something */
Integer j = new Integer("1"); /* or something */
i = Integer.Add(i, j); /* the old 'i' gets GC'ed */
j = Integer.Xor(i, j); /* the old 'j' gets GC'ed */
foo.Println(i.ToString()); /* print the value of 'i' by magic */
possibly with some syntactic sugar, but the 'Integer' type has no
mutator methods.
I guess another way to write what I was thinking is to give 'Integer'
some mutators, the same way you can give mutators to your own classes
in real Java:
void swapTakeTwo(Integer i, Integer j)
{
Integer k = new Integer(i); /* copy constructor */
i.SetValueTo(j); /* takes an Integer param, mutates the object */
j.SetValueTo(k);
/* around here 'k' can be GC'ed */
}
Note that 'SetValueTo' is a method that gets applied to the object
"pointed to by" the reference called 'i', so it does indeed change
the "integer" i's "value" back in the caller. I agree that as in
real Java,
void notSwapping(Integer i, Integer j)
{
Integer k = i;
i = j;
j = k; /* uselessly shuffling local pointers */
}
wouldn't swap these "objecty" Integers.
-Arthur
Oliver Wong
"Arthur J. O'Dwyer" <a...@nospam.andrew.cmu.edu> wrote in message
news:Pine.LNX.4.60-041....@unix45.andrew.cmu.edu...
>
Yes, aside from the statement of it being "dumb", I think you understood
completely. ;)
- Oliver
Dave Vandervies
blm...@myrealbox.com <blm...@myrealbox.com> wrote:
>In article <Pine.LNX.4.60-041....@unix45.andrew.cmu.edu>,
>Arthur J. O'Dwyer <a...@nospam.andrew.cmu.edu> wrote:
>> Well, at least it would get rid of my objection that Java's object model
>>is "inconsistent" or "unintuitive." I'd still /prefer/ the C(++) model,
>>but at least if everything in Java were an Object passed by reference
>>(or "by-value-but-where-that-value-is-itself-a-reference" ;) it would
>>be obvious what any code did, once you learned one rule, instead of having
>>to learn Rule A for objects and Rule B for primitives (and Rules C-Z
>>telling you which standard identifiers refer to primitives and which to
>>object types).
>
>But there really is only one rule, once you understand that
>"MyObject x" *is not a MyObject, but a reference to a MyObject*
>(where "reference" is to be interpreted as "less dangerous /
>less powerful relative of pointer" and not as whatever C++ means
>by "reference").
Do you have an easier way to acquire that understanding without (a)
understanding pointers and indirection already and (b) figuring out
that the the people who tell you "Java is better because it does away
with those scary sharp dangerous pointers" are not just lying to you
but actively interfering with your ability to understand the annoying
unweildy blunt references it replaces them with?
When I first learned Java (already knowing C), nobody said anything about
pointers, or indirection, or reference/reference-ish/value semantics,
or anything of the sort. The Java reference and argument-passing model
finally started to make sense when I realized that it DOES have pointers,
it just tries to hide them (and fails miserably).
>But I'll try to shut up now, since I'm pretty sure those of you
>who find Java a mass of confusion aren't going to be swayed by yet
>another round of "it's all simple when viewed from the right angle."
Any mass of confusion is all simple when you view it from the right angle;
the real problem with Java is that looking at it from the right angle is
a lot harder than it needs to be, and (as far as I can tell) pretty much
requires already understanding something where that angle is *obviously*
the right angle to look at it from.
(Corollary: Anything, no matter how simple, becomes a mass of confusion
when viewed from the wrong angle.)
>> (BTW, I'm assisting in an introductory C course this semester, and I do
>>find that students who learned Java first have a hard time understanding
>>explicit pointers. I doubt many people who learn explicit pointer-passing
>>first find it difficult to grasp Java's syntax, which is basically "delete
>>all the asterisks from C++.")
>>
>
>Well, I don't know. I would claim, with all due respect, that
>*you* seem to be having a certain amount of difficulty with --
>not Java's syntax, maybe, so much as its semantics? "Delete all
>the asterisks from C++" seems to be an oversimplification; e.g.,
>"MyObject x" means something different in C++ from what it means
>in Java.
It does mean something remarkably similar to what "MyObject *x" means
in C++, though.
dave
--
Dave Vandervies dj3v...@csclub.uwaterloo.ca
Yes, I've seen some of those - one was miniature elephants waving their
trunks. I didn't think it added to readability, but that's just my opinion.
--Alan Balmer in comp.lang.c
Gerry Quinn
says...
As I said, I assume it is specified somewhere and that the former
option (i.e. one implicit string creation) is chosen for efficiency.
- Gerry Quinn
blm...@myrealbox.com
Dave Vandervies <dj3v...@csclub.uwaterloo.ca> wrote:
>In article <3u2d0oF...@individual.net>,
>blm...@myrealbox.com <blm...@myrealbox.com> wrote:
>>In article <Pine.LNX.4.60-041....@unix45.andrew.cmu.edu>,
>>Arthur J. O'Dwyer <a...@nospam.andrew.cmu.edu> wrote:
>
>>> Well, at least it would get rid of my objection that Java's object model
>>>is "inconsistent" or "unintuitive." I'd still /prefer/ the C(++) model,
>>>but at least if everything in Java were an Object passed by reference
>>>(or "by-value-but-where-that-value-is-itself-a-reference" ;) it would
>>>be obvious what any code did, once you learned one rule, instead of having
>>>to learn Rule A for objects and Rule B for primitives (and Rules C-Z
>>>telling you which standard identifiers refer to primitives and which to
>>>object types).
>>
>>But there really is only one rule, once you understand that
>>"MyObject x" *is not a MyObject, but a reference to a MyObject*
>>(where "reference" is to be interpreted as "less dangerous /
>>less powerful relative of pointer" and not as whatever C++ means
>>by "reference").
>
>Do you have an easier way to acquire that understanding without (a)
>understanding pointers and indirection already and (b) figuring out
>that the the people who tell you "Java is better because it does away
>with those scary sharp dangerous pointers" are not just lying to you
>but actively interfering with your ability to understand the annoying
>unweildy blunt references it replaces them with?
Well .... The people who seem hardest to convince that there really
is only one rule are the people who come to Java with a fairly strong
background in C++. Those people presumably do understand pointers and
indirection already, but they also have ideas about what "reference"
and "MyObject x" mean that are at odds with their meanings in Java.
I agree that overly broad statements about Java not having pointers
are more likely to hinder than help. ("If it has no pointers,
how do you make a linked list?" is a question I used to hear a
lot from people new to the language, though not so much recently.
Maybe I just don't notice any more.)
>
>When I first learned Java (already knowing C), nobody said anything about
>pointers, or indirection, or reference/reference-ish/value semantics,
>or anything of the sort. The Java reference and argument-passing model
>finally started to make sense when I realized that it DOES have pointers,
>it just tries to hide them (and fails miserably).
>
Well, I would describe this as "it *does* have pointers, but what you
can do with them is more restricted than what you can do with C/C++
pointers, and the restrictions are aimed at making it more difficult
to make common mistakes, with the usual consequence that some things
experts might like to do are more difficult or even impossible."
But then I rather like Java, and it sounds like you don't.
It sounds like maybe the explanations of Java you were initially
given were, hm, somewhat lacking. Since you already knew C, did you
ask questions such as "how do you make a linked list in Java"? If
so, what was the response?
>
>>But I'll try to shut up now, since I'm pretty sure those of you
>>who find Java a mass of confusion aren't going to be swayed by yet
>>another round of "it's all simple when viewed from the right angle."
>
>Any mass of confusion is all simple when you view it from the right angle;
>the real problem with Java is that looking at it from the right angle is
>a lot harder than it needs to be, and (as far as I can tell) pretty much
>requires already understanding something where that angle is *obviously*
>the right angle to look at it from.
>(Corollary: Anything, no matter how simple, becomes a mass of confusion
>when viewed from the wrong angle.)
>
Like I said, the people who seem to have the most trouble with
Java are the ones who one would think *do* understand pointers and
indirection. Possibly a source of confusion is the "same syntax,
different semantics" I mentioned in another post ("MyObject x"
means different things in C++ and Java). Possibly whatever route
these people are taking to learning Java doesn't explain this well.
Bad explanations are, alas, not uncommon.
I don't know about people who start out in Java. Possibly they
also are confused. Again I would say the problem may be bad
explanations. But I'm not betting either way.
>
>
>>> (BTW, I'm assisting in an introductory C course this semester, and I do
>>>find that students who learned Java first have a hard time understanding
>>>explicit pointers. I doubt many people who learn explicit pointer-passing
>>>first find it difficult to grasp Java's syntax, which is basically "delete
>>>all the asterisks from C++.")
>>>
>>
>>Well, I don't know. I would claim, with all due respect, that
>>*you* seem to be having a certain amount of difficulty with --
>>not Java's syntax, maybe, so much as its semantics? "Delete all
>>the asterisks from C++" seems to be an oversimplification; e.g.,
>>"MyObject x" means something different in C++ from what it means
>>in Java.
>
>It does mean something remarkably similar to what "MyObject *x" means
>in C++, though.
>
Exactly -- a point I made in another post in this thread. Glad
someone agrees (since my C++ is sufficiently rusty for me to be a
bit unsure).
blm...@myrealbox.com
It's not really a matter of efficiency, though. The efficiency
optimization, if any, comes in creating only one String object for
code such as the following:
String a = "hello";
String b = "hello";
The fact that String objects are not copied during method invocation
isn't an efficiency optimization; it's a consequence of the fact that
what is being passed to the method is not a String object, but a
reference to a String object -- similar to passing a pointer in C++.
I think this brings us to some point that's already been visited,
though, so we may be done (and will have to agree to disagree).