Jesse Liberty said:
I won't argue the point with you (it becomes a matter of religion) but
depending on the audience, I often say that "objects are passed by
reference."
Yes, everything in C# is passed by value, and yes a copy of a reference to
the unnamed object in memory is passed, but that creates the semantics of
pass by reference and the effect is (nearly all the time) identical. The
distinction should be covered in a note, and then forgotten, as far as I'm
concerned.
I disagree strongly (as I'm sure you'd guessed
![Smile :) :)](/styles/default/custom/smilies/smile.gif)
- I've seen lots of
people who've been confused precisely because people are inexact in
this kind of thing. You may not confuse people who don't actually know
what pass-by-reference semantics are in the first place, but you'll
certainly confuse those who do. If you really believe this inaccuracy
doesn't do any harm, I'm sure I can easily dig up a whole stack of
posts by people on both the Java and C# groups who've been confused by
this but have then been "unconfused" by the correct view. I've never
seen anyone (AFAICR) end up being confused by the correct view
It's not just that the semantics of pass-by-reference and pass-
reference-by-value are different when the parameter's value is changed
- it's that if you've got the right idea of references to start with,
passing a reference by value is actually a far more natural thing to
talk about anyway.
The difference between a reference and an object is absolutely vital to
understanding C#, and once that difference is understood, things like
assignment, parameter passing, garbage collection, reference identity
versus object equality etc are *so* much easier to understand. The idea
of passing an object by reference gets very strange when things like
nulls get involved, and certainly when you then *do* pass the reference
by reference things get even more complicated. Why choose the
complicated and technically inaccurate way of describing parameter
passing rather than the simple and technically accurate way?
Similarly, if I declare
Dog fido = new Dog("fido");
I will often refer to fido as a Dog, or as a Dog object or even as an
instance of a Dog, none of which is technically correct, because of course
fido is just a reference to an (unnamed) Dog object on the heap.
(In fact, fido is just a variable. The *value* of fido is a reference
to a Dog object on the heap. But never mind that...)
I hope that if you were talking about the topic of assignment itself,
you'd be accurate. It's okay (IMO) to be technically slightly
inaccurate when the point you're actually making is unrelated to the
technical inaccuracy. When you're actually trying to explain parameter
passing though, being inaccurate about parameter passing is a really
bad idea.
It is important in a primer to be correct, but it is also important to be
clear, and pointless legalistic distinctions often just get in the way.
Agreed - but bearing in mind the point above, I believe on this matter
it's easy to be correct *and* clear. At least, that's my experience
over the last few years of "crusading" to get this inaccuracy cleared
up - it's one of my pet peeves. Fortunately the C# books I've read have
tended to be much more accurate about this than the early Java books,
so there's less confusion out there this time around, although it still
happens.
Guess you'll hate my books <smile>.
Maybe I'll find out one of these days
![Smile :) :)](/styles/default/custom/smilies/smile.gif)