A question on modification of a list via a function invocation

[Steve D'Aprano]

On Tue, 5 Sep 2017 11:47 pm, Gregory Ewing wrote:

> Steve D'Aprano wrote:
>>     [quoting Scott Stanchfield]
>>     Figure 7: (Java) Defining a Dog pointer
>>     Dog d;
>> 
>>     When you write that definition, you are defining a pointer to a Dog
>>     object, not a Dog object itself.
>>     [end quote]
>> 
>> Here Scott mixes up what the compiler does (creates a pointer to a Dog
>> object, and what the programmer's Java code does (creates a Dog).
> 
> Um, no. The declaration 'Dog d' on its own does NOT create a Dog,
> in any way, shape or form. It only declares something that can
> *refer* to a Dog created elsewhere, which is what Scott is
> quite correctly saying.

That's not what he said. I quoted him: he quite clearly states that d defines a
pointer to a Dog object. He doesn't say that you're declaring an empty slot
that is waiting to be filled with a pointer to a dog. He says it defines a
pointer.

So which Dog object does this pointer point to? Answer: there isn't one. There
may not even be any Dog object existing in the entire program up to this point.

Even allowing that there were a Dog to be pointed to, how do we inspect or
manipulate that pointer? Answer: you can't, because pointers are not meaningful
values in Java.

There's no(?) Java code you can write that allows this:

    Dog d;
    java.lang.System.out.println( address of variable d );
    java.lang.System.out.println( address of the Dog d points to );

Maybe compiler-specific debugging tools? I don't know enough Java to
*categorically* rule it out, but if it exists at all, it would be unsafe to
rely on the addresses you get.

You're right that I made a mistake. I'm not a Java expert like Scott
Stanchfield, and I was led astray by his misleading explanation, and failed to
notice that d didn't have a value. (What's his excuse for not noticing?)

As Stefan already pointed out, the code Scott gives does not define a value, but
is just a declaration of a variable name. At that point, d has no value at all,
and you get a compile time error if you try to access d. There is no Dog, and
no pointer to a Dog. There's just a name (or variable if you prefer).

So what's the value of d? It doesn't have one. Scott's explanation is
misleading: `Dog d;` does not define *any value at all*, let alone a pointer.

I daresay that Scott could attempt to justify his wording. I imagine it might go
something like this:


    Of course d is a pointer to a value. The Java compiler keeps a table
    mapping variable names to memory addresses, and the name 'd' is mapped
    to some address in the table. That address must hold some value, even
    if it is uninitialised memory filled with arbitrary bytes. That address
    is a (possibly null, possibly invalid) pointer to a Dog object.
    -- Me, channelling what I think Scott *might* say.

Notice how this mixes *three* different abstractions? There's the top-level Java
abstraction, where we declare d as a Dog. There's the compiler abstraction,
where we talk about mapping variable names to memory addresses, and pointers to
Dog objects. And there's an even lower abstraction, where we talk about memory
filled with arbitrary bytes.

And so long as we keep track of which abstraction we're in, this is fine. It
doesn't even have to be explicit: once people gain enough experience, they can
effortlessly and implicitly swap between abstractions and not even notice.
That's sometimes a good thing, but its a bad thing when we lose track of the
abstraction level and confuse others (like me!), or even ourselves, and lead
to "Not Even Wrong" questions like this:

https://stackoverflow.com/questions/1961146/memory-address-of-variables-in-java

(Likewise for people thinking that id() in Python returns a memory address, and
ask how to dereference that address.)

Not all explanations are equally useful, even if they are correct for some
definition of "correct".


In Python, the equivalent to Scott's code `Dog d;` would be something like this:

# --- %< ---

class Dog:
    pass

global x
assert isinstance(x, Dog)

# --- %< ---

except that we get a runtime NameError instead of a compile-time error. Would
you like to say that this code "defines a pointer to a Dog"? I should hope not.
How is it different from Scott's example of `Dog d;`?



>> I expect this is because, as a "compiler guy", Scott probably doesn't really
>> believe that objects are values.
> 
> Please stop insulting Scott's intelligence, and that of other
> "compiler guys", by suggesting that they don't understand things
> as well as you do.

Why shouldn't I suggest that Scott got something wrong? What makes him, and
other "compiler guys", so special that they are infallible and can't make
mistakes? Argument by authority is at best the weakest form of argument, if it
isn't an outright fallacy.

https://en.wikipedia.org/wiki/Argument_from_authority

I'm not questioning his intelligence. I'm questioning his *perspective*, and his
failure to distinguish between different levels of abstraction. I'm not
questioning his understanding of how the Java compiler works, or what the
standard says.

In fact, my failure was to question Scott's authority sufficiently: if I were
more questioning, I would have realised that his Dog example ("Figure 7" in the
quoted text above) is not just the wrong perspective (as I initially thought)
but *outright* wrong: d has no value at all, it is an uninitialised variable.

(Thanks again Stefan for pointing that out.)

Greg, you are really scraping the bottom of the barrel to stoop to falsely
accusing me of insulting Scott's intelligence. Your argument here is an
argument from outrage: how dare I insult Scott by claiming he is wrong.

Scott himself claims that the Java standard makes a mistake to use the term
reference when they mean pointer:

    The problem here is that the folks at Sun made a naming mistake.
    ... They went so far as to try a different name for the concept,
    formally calling them "references". A big mistake and it's caused
    even more confusion in the process.

Are you going to accuse Scott of "insulting the intelligence" of James Gosling
and the rest of the Sun team?




-- 
Steve
“Cheer up,” they said, “things could be worse.” So I cheered up, and sure
enough, things got worse.