Finding the instance reference of an object

[Joe Strout]

On Nov 5, 2008, at 2:06 PM, Lie wrote:

>> <http://www.strout.net/info/coding/valref/>
>
> I'm fed up with you.

I'm sorry -- I'm really not trying to be difficult.  And it's odd that  
you're fed up with me, yet you seem to be agreeing with me on at least  
most points.

> In Von Neumann Architecture computers, only pass-by-value is natively
> supported. Other idioms are made on top of pass-by-value.

Well, sure.  But a language may or may not naturally support the others.

> That's why exclusively pass-by-value languages like C is most flexible
> than other exclusively pass-by-<insertanythinghere>.
>
> BUT the difference is clear, if you want to do pass-by-reference in C
> (I prefer to call it faux pass-by-reference), you'd have to manually
> find a variable's address, pass it by-value, then dereference the
> address.

Agreed.

> Compare with VB's ByRef or C++'s &, which does all that
> _automatically_ for you behind the scene.

Agreed again.

> Another example: pass-by-object.

Here's where we depart, I guess.  I think there's no such thing (see <http://en.wikipedia.org/wiki/Evaluation_strategy 
 > for example, and the dead-tree references I have on hand agree).

> I disagree with the term pass-by-object-reference, since the notion
> of object reference is unnecessary
> in a true pass-by-object mechanism (i.e. we should travel outside VNA
> realm for a true pass-by-object mechanism). Problem is: I'm not aware
> of any computer architecture that can accommodate pass-by-object
> natively or whether such architecture is feasible to be made.

I don't think it's necessary (or helpful) to reach down into the  
architecture or implementation details.  What matters is the behavior  
as seen by the language user.  Variables in a language could hold  
actual object data (in which case "a = b" would copy the data from b  
into a), or they could hold just references to object data that lives  
elsewhere (in which case "a = b" would copy that reference, giving you  
two references to the same object).  In Python, they are of course  
just references.

Then, and completely independent of that, variables could be passed  
into a method by value or by reference (or by several other more  
esoteric evaluation strategies that are rarely used, but "call by  
object" isn't one of them).  Again, it's easy to tell these apart with  
a simple behavioral test.  Python passes its object references by  
value; changes to the formal parameter have no effect on the actual  
parameter.

> In pass-by-object, the whole object is passed around, not a copy of
> the object like in pass-by-value or a copy of the pointer to the
> object like in faux pass-by-reference.

I can't understand what that would mean, unless we imagine the  
variable actually containing the object data; but it doesn't, or "a =  
b" would copy that data, which clearly it does not.

Understanding that a name in Python is merely a reference to the  
object, and not the object itself, seems to me to be one of the  
fundamental truths that any beginning Python programmer must know.

> This makes pass-by-object
> actually closer to pass-by-reference than to pass-by-value, since the
> notion of VNA's requirement for Object Reference means passing
> pointers around. But don't let it confuse you, the pass-by-object
> mechanism itself does not recognize Object Reference, unlike pass-by-
> reference recognition of reference/pointer.

Sorry, it's confusing me whether I want it to or not.

And here's what I don't understand: object references are so simple,  
why do people go to such great lengths to pretend that Python doesn't  
have them, resulting in a far more complex and convoluted explanation  
that is much harder to understand?

> Now that I have clearly defined the line between pass-by-object and
> pass-by-value, I'm left with you thinking what's the difference
> between pass-by-object and pass-by-reference.

If they're that hard to tell apart, then Python doesn't have either,  
since it is very clear and obvious that Python does not have pass-by- 
reference (since you can't write a function to swap two parameters,  
for example).

> In pass-by-reference, names are _mnemonic to location in memory_.
> In pass-by-object, names are _mnemonic to objects_.

These would be equivalent if objects live at some location in memory,  
wouldn't they?

> In pass-by-reference, when we assign a
> value to the name, we'd assign a value _to the location in memory_. In
> pass-by-object, when we assign a value to the name, we assign an
> object _to the name_. When passing parameters, pass-by-reference
> systems passed the memory address and alias that memory address to a
> local name. In pass-by-object system, since the object itself has no
> idea of its own name, so it is rebound to a local name. You can say
> that pass-by-reference system is memory-location-centered, while pass-
> by-object system is name-centered.

Hmm. I can only interpret "the object is rebound to a local name"  
sounds the same to me as "a local variable is assigned a reference to  
the object."  Can you explain how they're different?

I see how what you're describing is different from pass by reference;  
I just don't see how it's any different from pass by value.

> To summarize, the key bit you're missing is built-in _automatic_
> abstraction from pass-by-value. All pass-by-<insertanything> except
> pass-by-value is an emulation over an architecture that can only
> natively pass-by-value.

Yes, OK, that's great.  But there are several standard pass-by- 
somethings that are defined by the CS community, and which are simple  
and clear and apply to a wide variety of languages.  "Pass by object"  
isn't one of them.  I guess if you want to campaign for it as a  
shorthand for "object reference passed by value," you could do that,  
and it's not outrageous.  But to anybody new to the term, you should  
explain it as exactly that, rather than try to claim that Python is  
somehow different from other OOP languages where everybody calls it  
simply pass by value.

> pass-by-reference is emulated in C, C++, and
> VB by passing memory address/pointer but C isn't a by-ref system
> because C doesn't provide the automatization.

Yes, that's true of C.  I never argued that C had a by-ref mode.  C++,  
VB, and REALbasic all do, however.  Python and Java do not.

> What makes python's parameter passing called as pass-by-object is  
> because python provides
> the automatization to make it seems that you can do true pass-by- 
> object.

OK, if there were such a thing as "pass-by-object" in the standard  
lexicon of evaluation strategies, I would be perfectly happy saying  
that a system has it if it behaves as though it has it, regardless of  
the underpinnings.

My objection to this term is simply that it is made up and  
nonstandard, and adds no new value to the discussion.  To me, "object  
references passed by value" is simple and clear, where as "pass by  
object" means nothing (until you explain that it means the former).

However, if you really think the term is that handy, and we want to  
agree to say "Python uses pass by object" and answer the inevitable  
"huh?" question with "that's shorthand for object references passed by  
value," then I'd be OK with that.

Best,
- Joe