Modifying Class Object

[Steve Howell]

On Feb 14, 7:11 am, Steven D'Aprano <st... at REMOVE-THIS-
cybersource.com.au> wrote:
> On Sat, 13 Feb 2010 23:45:47 -0800, Steve Howell wrote:
> > The term "pointer" is very abstract.  Please give me a concrete
> > definition of a pointer.
>
> A programming language data type whose value directly specifies (or
> "points to") another value which is stored elsewhere in the computer
> memory.
>
> I quote from Wikipedia:
>
> http://en.wikipedia.org/wiki/Pointer_(computing)
>
>     [quote]
>     A pointer is a simple, less abstracted implementation of the
>     more abstracted reference data type
>     [end quote]
>
> And later:
>
>     [quote]
>     While "pointer" has been used to refer to references in
>     general, it more properly applies to data structures whose
>     interface explicitly allows the pointer to be manipulated
>     (arithmetically via pointer arithmetic) as a memory
>     address...
>     [end quote]
>
> And again:
>
>     [quote]
>     A memory pointer (or just pointer) is a primitive, the value
>     of which is intended to be used as a memory address; it is said
>     that a pointer points to a memory address. It is also said that
>     a pointer points to a datum [in memory] when the pointer's value
>     is the datum's memory address.
>
>     More generally, a pointer is a kind of reference, and it is said
>     that a pointer references a datum stored somewhere in memory; to
>     obtain that datum is to dereference the pointer. The feature that
>     separates pointers from other kinds of reference is that a
>     pointer's value is meant to be interpreted as a memory address,
>     which is a rather 'low-level' concept.
>     [end quote]
>
> > A curly brace is one of these: { }
>
> > Pretty concrete, I hope.
>
> But { and } are glyphs in some typeface. Chances are that what you see,
> and what I see, are quite different, and whatever pixels we see, the
> compiler sees something radically different: two abstract characters
> implemented in some concrete fashion, but that concrete fashion is a mere
> implementation detail. They could be implemented as bytes x7b and x7d, or
> as four-byte sequences x0000007b and x0000007d for UTF-32, or who knows
> what in some other system. So the *concrete* representation of the curly
> brace varies according to the system.
>
> From that, it's not a difficult leap to say that Pascal's BEGIN and END
> key words are mere alternate spellings of the abstract "open curly brace"
> and "close curly brace" with different concrete representations, and from
> that it's a small step to say that the INDENT and DEDENT tokens seen by
> the Python compiler (but absent from Python source code!) are too.
>

Thanks.  It's a useful analogy; I think I understand your point
better.  I've been bouncing around between Python and Javascript a lot
lately, so your analogy resonates with me.  There are many times when
I find myself simply respelling things like begin/end, and those
respellings to me almost make me think of Python and Javascript as
different dialects of an underlying language.  Of course, there are
other places where the languages differ more substantively, too.

Going back to pointers vs. references, I think the key distinction
being made is that pointers allow specific memory manipulation,
although I think even there you're really just dealing with
abstractions.  The address 0x78F394D2 is a little bit closer to the
machine than, say, the 42nd element of a Python list, but they are
both just abstractions on top of underlying machines, whether the
machines are virtual, electronic circuits, vacuum tubes, whatever.
You can add 6 to 42 and get the 48th object, but its Python's
convention not to call the 48th object a memory address or expose a
reference to it as a pointer.  If I want to pass along the reference
to the 48th element of a list as the slot to be updated (i.e. with the
intention to actually mutate the list itself), then I need a tuple
like (lst, 48).