Maybe this is a stupid question, but I'm going to ask anyway... How can the foo inside someFunc still point to Integer(1) when it's a new Integer object with a value of 2? Can a new object with a different value still hold a reference to a different object with a different value? (Edit: or were you referring to the foo outside of someFunc?)

Also just a quick note: I was playing around a little with this code and modified the code inside someFunc() to "foo = 2" expecting the value of foo outside the method to change to 2, but it stayed at 1.

Started to question everything I thought I understood about this before I remembered that Integer is immutable.

"object references are passed by value"? It's called a pointer, guys.

ah, the magic of java...

This is the exact opposite of how Java the language sees things. Objects don't even really exist in Java, only object references. Variables cannot hold values of objects because "a value of an object" isn't even a thing in Java.

One problem is that we're using the term "reference" in too many places. This isn't what's meant by pass-by-reference. Almost every language has a reference/pointer type of some kind - if that meant passing by reference, than every language that has pass-by-value has pass-by-reference and it's dependent upon variable/value types. Pass-by-reference, in programming language parlance, means parameters are aliases to the arguments in the caller's scope, as opposed to variables in the callee's scope with values copied from the arguments. This is most assuredly what's not happening in Java. I think if you call Java's object references simply object pointers (which they are), it becomes more clearer.

You're confusing the lies we tell ourselves with language semantics. In Java, only object references are actual values and objects don't even need to exist, except to satisfy the operations on the references. And function invocation isn't the only place this happens. Every place where there would be a difference between treating the variable as holding the value of the reference and the value of the object, Java treats the variable as holding the value of the reference. For instance:

House a = new House();
House b = a;

Now b and a have the same value! Would you treat this as some kind of special Java semantics where variable assignment somehow results in aliasing if and only if the value involved is the object or simply note that assignment always results in copying values, it's just that copying references doesn't result in copying objects, merely two variables having the same reference values to the same object? Return values? Member variables? Nulls? Is null a valid object? Is it a valid object reference? There's no getting around to learning that in Java, the value of an object type is always an object reference.

jj made a small mistake using the same variable name both inside and out. Try this:

This is irrelevant. If you implemented MutableInteger, you'd get the same result for that code. Where mutability matters is if you use mutating operators, as opposed to variable assignments. For instance:

I have computer engineering degree so not a computer science degree so take this FWIW. I took 2 years of Calculus which includes a semester of differential equations. I hesitate to say I have used that knowledge in software zero percent but it is very close to zero.

Candybar - this is a semantic issue. But as soon as you say "Objects don't even really exist in Java, only object references" - as far as I'm concerned you're playing a super semantic game that isn't really useful. And that's exactly my point - you need to get super semantically picky to make the "Everything is passed by value" argument and that doesn't mesh with how we typically talk about the language (for example - Java goes to great lengths to convince us that Objects exist).

The foo inside someFunc starts pointing to the Integer(1) object but after the assignment points to the Integer(2) object.

Outside the scope of someFunc foo is always pointing to Integer(1).

It would have been clearer if I hadn't used foo in both places.

FWIW I agree with you. Interesting discussion.

Ok got it now. Thanks.

Except, if you go by your semantic strategy, you have a completely different set of semantic rules for primitives and Objects in every context. As I pointed out, simple assignments appear to have completely different meanings (in fact function-invocation semantics in Java is simply assignment semantics), not to mention data structures, circular structures aren't even describable without knowing that variables hold references. I suppose you can get there with some complex aliasing rules, but it's a complete mess. Null is another big problem. My semantic approach has the advantage of being the actually accepted nomenclature, reflecting the actual implementation strategy and also making semantic rules simpler and removing unnecessary rules.

Your approach also sets people up for failure when they have to actually work with language that have call-by-reference semantics because it teaches them literally the wrong terminology. To get the same semantics as in Java in languages with both call-by-value and call-by-reference, they have to use call-by-value.

And no one's saying objects don't exist in Java. I'm saying your conception of the object as a value as a separate thing from the object reference is not an actually valid value or in anyway addressable within the language itself. And you desperately need that concept to be a meaningful value, because otherwise what would be call-by-value semantics for objects? What value would be passed and copied? On the contrary, we can easily imagine an actual call-by-reference semantics for Java and it would work different than how it does now. In short, if Java can add call-by-reference semantics that works very differently than it does, but cannot add call-by-value semantics that works any differently that it does now, how can you call what we have call-by-reference?

In terms of how people discuss things, people most of the time just say objects to refer to object references, or when they are being precise, the thing on the heap that that the object variable points to. But it's important to know that when you're talking that object, it's not a valid value in Java.

Ok, got that too!

Except this: bar = new MutableInteger(2)

That's instantiating a new object so it's never going to point back at foo, correct? (I believe it's essentially the same as using an assignment operator on Integer, since when you do that a new object is also instantiated.)

But I understand your point about mutating operators (never heard that phrase but basically setter methods, yes?) versus variable assignments. Somehow I've missed that key point and am going to have to go back over that stuff and nail it down.

Correct. As noted in the comments, .set() change propagates to foo, but assignment doesn't. I think jj mentioned this earlier but it really helps at the beginning to do the whole box and arrow thing to make sure you understand this completely.

Candybar, I'm not sure I'm explaining myself well. But, yes, I'm ok with having different semantics for primitives and objects in this context. That's inherent in saying that primitives are passed one way and objects another. It's also relevant in other parts of the language (primitives can't be null).

Let me try a different way of explaining it. I'm approaching this from the user (aka developer) point of view. The abstraction of Object is very different than the abstraction of primitives. When we talk about various Java features/properties we often refer to the different abstractions.

You seem to be approaching this from the low level implementation point of view. That's totally valid. But it's just as reasonable (and slightly more reasonable imo) to stick to the higher level when answering this question.

As for the comment about setting people up for failure in different languages:

1. I don't really care.
2. I don't agree. Developers need to be able to talk at different levels of abstractions. And always using highly specific language-agnostic concepts doesn't seem practical to me.

Not just in this context, but every context. Do you realize a = b has to be understood in terms of aliasing, which is a very difficult and complex concept, instead of simple copy assignment, to preserve Java's semantics without conceptualizing a and b as variables that hold values of references? Do you realize that to understand aliasing, you have to understand pointer/references/indirection anyway? So what's the point of all this teaching two sets of rules for every case a value is assigned (function invocation, assignment, return value, object initialization, etc) if the result is that your student has to know how pointers work anyway? Why not just tell him, well the object variable holds a pointer, and if you treat the value of the pointer as the value of the variable (which it is in every conceivable context in the language!) then all the rule are the same?

And don't get me started on things like shared state between threads and what not, where your semantic rules will completely break down. There's no way around knowing actually how things work and pretending that variables hold anything other than object pointers is simply going to hurt. I don't think you appreciate how complex language semantics are, even as they are, especially under degenerative conditions. There's no real reason to complicate them even further by making up things that aren't there.

Except, variables of object types in Java hold pointers and other than that, all rules are the same is a much simpler abstraction than what you're proposing! Say, you have a Javascript function that takes functions as arguments. Do you explain to students that function arguments are passed by name where the body of the function argument is passed without evaluation, then evaluated when invoked, or do you explain to them that everything's passed by value, it's just functions are valid values in javascript and this is how functions, as values work.

You want your students to be able to conceptualize how simple rules can combine to do more powerful things. This is what abstractions are about. A laundry list of combinations of things as all special features of the language is precisely the wrong way to think about languages. Call-by-value. All assignment is copying. Object types hold values, which are pointers to actual things allocated on the heap. This is far simpler than well, call-by-value here, call-by-reference here, assiginment is copying here, aliasing there, returning values there's aliasing here, yadayadayada.

Variables in Java holding pointers to objects isn't some low-level implementation detail, it's one of the defining features of the language.

Then don't use the terms! Nothing forces you to use terms like call-by-value or call-by-reference to describe Java's semantics. But you're doing them a disservice if you deliberately misuse the terms.

It's times like these when I remember that old linux fortune cookie about Niklaus Wirth

Looking for a good developer to help with a rails project. If anybody is interested, or knows somebody that might be, please let me know.

I knew I shouldn't get into this...

Could you point me toward an article/literature that explains this well?

By the way Candybar, reading that quote, I should point out that I understand exactly what you're saying and agree with you from a technical point of view. I just don't agree with you in terms of how we talk about this in many situations.

As far as I'm concerned you're vastly overstating the importance of being super precise in all of these situations - especially with respect to new students.

Edit: One last shot at an analogy. Ideally in physics we want to think about everything as a bunch of simple concepts and build up to really complex ****. But when you're talking about physics we often start with simpler models that might not be completely accurate (Newton's Laws, ignoring friction, etc.). In fact its fairly common to teach people simplistic views of the world and then dive deeper once they have that understanding. Even after someone has gained an understanding of the deeper concepts it can still be easier at times to frame the conversation in the simpler model of the world.

Pointers/indirection/references or aliasing? For the former, any really good book on C would do, as would something like SICP. Aliasing, I don't think you really want to get into it right now.

Sure, man, I don't doubt you understand, I'm just frustrated because it bothers me when people try to "simplify" by actually adding more fundamental complexity and also deliberately misuse technical jargon to fit their own mental model. It also bothers me when people don't explain things precisely and condescend you with "this will be easier for you to understand" explanations.

For instance, I had the misfortune of working in VB for a while and the language semantics is awful and complex and a lot of that complexity exists to turn what would otherwise be mistakes in sane languages into valid programs and to create special cases for all the things programmers may want to do, without regard to composition. The result is that I can never remember the rules because they don't make sense and are a long list of special cases. It's also hard to find out what the rules are because the culture surrounding the language is such that nobody explains VB semantics in precise, explicit language - almost all documentation and explanations you ever see is condescending nonsense that targets beginners. So you're never really sure how things are supposed to work, until you try.

Perhaps. I'm kind of mathy and was before I learned how to program, so non-precise, ambiguous descriptions or unnecessarily complex semantic rules bother me greatly. I'm definitely known to lose temper when people cargo-cult out of ignorance of simple language semantics (as in, I don't really know how this language/library feature works, so I'll just massage this copied-and-pasted bit until it works). Aping is necessary at first, but good programmer should quickly develop a clear, precise picture and be able to drill down when working on real products.

Well at least two of the questions were OOP (out of place) because they were not about OOP.

Unless of course...classes are objects.

And recursion which in most languages is just syntactic sugar (or vinegar depending on your POV) for loops. Now that's an answer that might get some interesting debates going

Do you guys think that working through one of those Programming Interview books would be worth my time/money?

Such as this one: http://www.amazon.com/Elements-Progr..._bxgy_b_text_z

1) Know your language+libraries (build stuff in it)
2) Know algorithms and datastructures (I'd rather get a book for this)
3) http://projecteuler.net/ and similar sites provide all the programing questions you could think of
4) Build stuff, see #1 -> You'll learn a ton of really important stuff that is implied in most interviews i.e. how to use your version control system of choice, value of tests etc.

[That book you linked looks interesting as a "collection of fun tasks" though. Wasn't aware that there are multiple of these]