Hacker News Reader

Comment by markbnj | Hacker News Reader

No, no, no there is no "call by object." It is precisely this mistaken idea which muddies the waters, as you put it. Virtually all modern processors are stack-based architectures. All arguments to functions are passed on the stack or in registers. The only thing that can be placed onto the stack or into a register are numbers. Those numbers can represent either an actual value or an address in memory. The former is call by value, the latter is call by reference. All high level languages that allow calling functions or methods with arguments have to ultimately use this facility to pass those arguments. Python is most definitely call by reference.

View on HN

Couple of things:

1. "Call/pass by XXX" terminology usually refers to language semantics, not underlying implementation details. In that respect, the call-stack mechanism is largely orthogonal here.

2. According to this oft-cited article (in the context of Java), passing an address under the hood is not sufficient to make a language call-by-reference. http://javadude.com/articles/passbyvalue.htm - AFAIK Python would "fail" the "Litmus test".

(EDIT - clarify what's not call-by-ref)

In Java, this code will print the string representation of Lassie:

  Dog toby = new Dog("Toby");
  
  public static void replaceDogWithToby ( Dog d )
  {
    d = toby;
  }
  
  public static void main ( String[] args )
  {
    Dog d = new Dog("Lassie");
    replaceDogWithToby(d);
    System.out.println(d);
  }

In Pascal, this will print Toby:

  var
    toby:tDog;
  
  procedure replaceDogWithToby ( var d:tDog );
  begin
    d := toby;
  end;

  var
    lassie:tDog;
  begin
    {code to initialize toby and lassie here}
    d := lassie;
    replaceDogWithToby(d);
    writeln(getDogName(d));
  end.

The first is call by object (or call by sharing, in my book). The second is call by reference. The behavior is totally different.

I haven't done java in a long time so I won't try to debate the specific language level semantics with you (the same is true of pascal though it has been even longer), however assuming that your examples run and behave as you describe then what is going on in the java example is that 'Dog d' is passed as a reference to a reference, and then the value pointed to by the argument, i.e. the address of "toby," is replaced with the address of "lassie."

You got it backwards. The Java snippet will print "Lassie". In Java, object names are references to objects, and passing them to functions copies the references, so of course modifying the formal parameter (d from replaceDogWithToby()) doesn't modify the actual parameter (d from main()).

"Variables in Python are object references. When you call a Python function the arguments are copies of the references to the original object." -- I personally wouldn't worry about what to call it(though call by reference would be my pick too), in the end I just visualize it as being similar to how assignment works in Python.

The confusion comes from the difference between references in Python and C++. In Python you can reassign a reference to a different object any time you want. In C++ you can't, and any attempt to do so modifies the referenced object instead. That fundamental difference makes it hard to understand the mechanics of Python using the terminology of C++.

Yes. But. Language designers go out of their way typically to hide this underlying truth, by for example implementing "call by value" when the type of the value is "Customer" or whatever.

It's specifically because high level language semantics often mask the underlying implementation that knowing that implementation is necessary for truly understanding what's happening. The situation you describe is call by reference, where the value passed on the stack or in a register is a reference to a customer object. You could pass a customer object by value (in languages that allow it, such as C++) by copying the structure verbatim onto the stack and addressing it there.

It may be implemented as call-by-reference, but the semantics are not the same as what one thinks of when he hears that phrase.

In what way are they different?

In a classic call-by-reference, changes you make to the passed parameter are seen by the caller when the function returns. That doesn't happen consistently with Python.

I think you're just using "classic" to mean the behavior of languages like C++. Under the hood there are only two ways this mechanism can function, and I don't think it helps to mix high level language semantics in when trying to explain it, as those semantics are always expressed in one of those two ways.

I'm using "classic" to refer to the way things were done when the terms were first invented. Old languages like C or Fortran.

Python uses references implicitly without ever defining the term, so it's essential to talk about the high level semantics in this case. A Python reference (implied) differs greatly from a C++ reference in that it can be rebound with the assignment operator. If you're thinking about references in C++ terms then Python will confuse you. It's important to call out the differences.

Im mostly experienced with the Lua Reference handling, so beware.

Usually there is one global hash-table, and a local hash table. Everything (every function, every object, every string is stored once, depending on the calling situation. So passing a reference to a object is passing the reference to that one global object, until you change it, or make a local copy of it. That sounds really strange and in a way is it. It also means, that your list of objects, will not contain duplicates. It means no useless work is done to copy data.

The model involved borrows basically from the concept of lazy loading and flat copys. Do work only when needed. Super difficult to explain to new users without CS background.

With anything immutable.

processors and architectures have nothing to do with this. This is a matter of semantics. The prolem stems from different communities appropriating the same english word to mean subtly different things, hence my clarification "in C++ lingo ..."

Reply on news.ycombinator.com