Finding the instance reference of an object

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Grant Edwards

    #46
    Re: Finding the instance reference of an object

    On 2008-10-29, Antoon Pardon <apardon@forel. vub.ac.bewrote:
    On 2008-10-17, Joe Strout <joe@strout.net wrote:
    >
    >>Python's assignment semantics (as opposed to its "object
    >>handling, a term for which I have no referent) are not the
    >>same as those of, say C.
    >>
    >They are, though. The only difference you've pointed out is
    >that *numbers* are different in Python vs. C, and that's an
    >internal implementation detail I was blissfully unaware of
    >until this discussion. (I'm grateful to know it, but it
    >really doesn't matter in day-to-day coding.)
    >
    No they are not. An assignment in Python is like making an
    (new) alias/reference, while an asignment in C is copying the
    content of one variable into another.
    That's been pointed out over and over and over, but some people
    seem unable or unwilling to grasp the difference.

    --
    Grant Edwards grante Yow! Someone in DAYTON,
    at Ohio is selling USED
    visi.com CARPETS to a SERBO-CROATIAN

    Comment

    • Dale Roberts

      #47
      Re: Finding the instance reference of an object

      On Oct 28, 11:59 am, Joe Strout <j...@strout.ne twrote:
      ...
      >
      There are only the two cases, which Greg quite succinctly and  
      accurately described above.  One is by value, the other is by  
      reference.  Python quite clearly uses by value.  Parameters are  
      expressions that are evaluated, and the resulting value copied into  
      the formal parameter, pure and simple.  The continued attempts to  
      obfuscate this is pointless and wrong.
      >
      Best,
      - Joe
      Joe, you are being too generous and expansive here.

      [Play along with me for a minute here...]

      Don't you know? There is really only *ONE* case, and, you are right,
      it is Pass By Value. There is no such thing as Pass By Reference at
      the physical CPU level at all, right? If there is, show it to me. Pass
      By Reference is just a silly idiom developed by high-minded CS
      academics to confuse the rest of us. It has no practical use and
      should not be given its own name, when we already have a good an
      proper name for it.

      Let me demonstrate with 3 examples of a function definition, and the
      appropriate calling syntax for that function in C++, all sharing the
      common "int i" global variable:

      int i = 5;

      myfunc(int &val){} /*CALL:*/ myfunc(i); // "ByRef" (ya, right!)
      myfunc(int val){} /*CALL:*/ myfunc(i); // ByVal
      myfunc(int *val){} /*CALL:*/ myfunc(&i); // Joe's ByVal

      The first is what all the fakers call "Pass By Reference" - sheesh,
      how naive. We all know that what *really* happens internally is that
      the *address* of val (A VALUE itself, or course) is copied and passed
      on the stack, right? There couldn't be a more straightforward example
      of Pass By Value (unless it's an inline function, or optimized away,
      or possibly when implemented in a VM, or...). It passes the *address*
      of i by value, then we can access the *value* of i too via
      indirection. Hmm, did we need to have two definitions of VALUE there?
      Well, never mind, no one will notice...

      The next is obviously pass by value. It's right out there. The value
      of i (which is what we are talking about, right?) is copied out, and
      passed right on the stack in plain daylight where we can all see it.

      How about the third? Pass By Value, obviously, of course. This is the
      version you are defending, right? The parameter's value, &i, is
      evaluated and copied right onto the stack, just like in the first
      example. In fact, if you compare the assembler output of the first and
      third examples, you may not even see a difference. Never mind the
      actual contents of that pesky "i" variable that most people are
      referring to when they use the term "value". We don't need to dress up
      example 3 and call it an "idiom" where we are really passing a so-
      called "reference" of the variable "i". Indeed! Don't insult our
      intelligence. We can all see that it's an address passed by value,
      plain and simple.


      Pass By Reference? So "postmodern ". Who needs it. Show me a so-called
      "reference" . I've looked at the assembler output and have never seen
      one. There is no such thing.

      "The continued attempts to obfuscate this is pointless and wrong."


      ---------------
      I hate to have to add this, but for those not paying close attention:

      ;-)

      dale

      (tongue back out of cheek now)

      Comment

      • Chuckk Hubbard

        #48
        Re: Finding the instance reference of an object

        On Wed, Oct 29, 2008 at 5:27 PM, Dale Roberts <gooberts@gmail .comwrote:
        Don't you know? There is really only *ONE* case, and, you are right,
        it is Pass By Value. There is no such thing as Pass By Reference at
        the physical CPU level at all, right? If there is, show it to me. Pass
        By Reference is just a silly idiom developed by high-minded CS
        academics to confuse the rest of us. It has no practical use and
        should not be given its own name, when we already have a good an
        proper name for it.
        >
        Let me demonstrate with 3 examples of a function definition, and the
        appropriate calling syntax for that function in C++, all sharing the
        common "int i" global variable:
        >
        int i = 5;
        >
        myfunc(int &val){} /*CALL:*/ myfunc(i); // "ByRef" (ya, right!)
        myfunc(int val){} /*CALL:*/ myfunc(i); // ByVal
        myfunc(int *val){} /*CALL:*/ myfunc(&i); // Joe's ByVal
        >
        The first is what all the fakers call "Pass By Reference" - sheesh,
        how naive. We all know that what *really* happens internally is that
        the *address* of val (A VALUE itself, or course) is copied and passed
        on the stack, right? There couldn't be a more straightforward example
        of Pass By Value (unless it's an inline function, or optimized away,
        or possibly when implemented in a VM, or...). It passes the *address*
        of i by value, then we can access the *value* of i too via
        indirection. Hmm, did we need to have two definitions of VALUE there?
        Well, never mind, no one will notice...
        >
        The next is obviously pass by value. It's right out there. The value
        of i (which is what we are talking about, right?) is copied out, and
        passed right on the stack in plain daylight where we can all see it.
        >
        How about the third? Pass By Value, obviously, of course. This is the
        version you are defending, right? The parameter's value, &i, is
        evaluated and copied right onto the stack, just like in the first
        example. In fact, if you compare the assembler output of the first and
        third examples, you may not even see a difference. Never mind the
        actual contents of that pesky "i" variable that most people are
        referring to when they use the term "value". We don't need to dress up
        example 3 and call it an "idiom" where we are really passing a so-
        called "reference" of the variable "i". Indeed! Don't insult our
        intelligence. We can all see that it's an address passed by value,
        plain and simple.
        >
        >
        Pass By Reference? So "postmodern ". Who needs it. Show me a so-called
        "reference" . I've looked at the assembler output and have never seen
        one. There is no such thing.
        You are so right! We also don't need "object-oriented programming".
        I looked at the motherboard and I don't see any objects moving around!
        I don't see any values being passed, either.
        When I turn on the TV and see Chuck Norris, though, I know it's only a
        reference to Chuck Norris, or I would be blinded. The only case he
        needs is "Pass By Roundhouse Kick".

        -Chuckk


        --

        Comment

        • Fuzzyman

          #49
          Re: Finding the instance reference of an object

          On Oct 28, 3:59 pm, Joe Strout <j...@strout.ne twrote:
          On Oct 27, 2008, at 11:28 PM, Gabriel Genellina wrote:
          >
          >
          >
          En Tue, 28 Oct 2008 00:58:10 -0200, greg  
          <g...@cosc.cant erbury.ac.nzesc ribió:
          >
          Let's look at the definitions of the terms:
          >
          (1) Call by value: The actual parameter is an expression. It is
             evaluated and the result is assigned to the formal parameter.
             Subsequent assignments to the formal parameter do not affect
             the actual parameter.
          >
          (2) Call by reference: The actual parameter is an lvalue. The
             formal parameter becomes an alias for the actual parameter,
             so that assigning to the formal parameter has the same
             effect as assigning to the actual parameter.
          >
          Seems to me that (1) describes exactly how parameter passing
          works in Python. So why insist that it's *not* call by value?
          >
          Greg is right on the money here.  It really is as simple as that.
          >
          Those definitions are only applicable to unstructured, primitive  
          types, where the only relevant operations are "get value" and  
          "assign value".
          >
          Nonsense.  They apply to any type.  See here for an introduction to  
          the topic in VB.NET:
          >
             http://www.homeandlearn.co.uk/net/nets9p4.html
          >
          The example shown uses an Integer, but guess what -- you can pass ANY  
          type either ByRef or ByVal, including object references (which are, of  
          course, quite common in VB.NET).  The default is ByVal, which means  
          that (as in Python) the actual parameter is an expression, and no  
          assignments to it can affect the actual parameter.  It DOES NOT MATTER  
          that both the formal parameter and the actual parameter may refer to  
          the same object, and if that object is mutable, you can mutate that  
          object.
          >
          You're pretty straightforward ly wrong. In Python the 'value' of a
          variable is not the reference itself. If that sentence has any meaning
          for Python then the value is the object itself.

          ..NET does draw a distinction between 'value types' and reference types
          - where using reference types are called by reference (the reference
          is passed) and value types are called by value (the value itself is
          copied).

          Value types (all numeric types, structs, enumerations etc) actually
          live on the stack, whereas reference types (strings, classes etc) live
          in the heap and have a
          pointer on the stack.

          It is complicated by the fact that .NET perpetuates the myth that the
          primitives (the value types) inherit from System.Object (a reference
          type). The runtime does auto-boxing for you where this matters.

          This means that when you pass a value type into a method the value
          *is* copied. Structs can be arbitrarily big, so this can be a
          performance problem. It is often a performance win for working with
          the numeric types as you remove a level of indirection.

          It isn't without problems though - and some of these can be seen in
          IronPython.

          System.Drawing. Point is a struct, but it is effectively a mutable
          value type. However, when you access it you are often accessing a copy
          - and if you attempt to mutate it then your changes will be lost.

          The following code illustrates the problem:
          >>r = Rectangle(0, 1002 20, 40)
          >>r.Location. X
          0
          >>r.Location. X = 20
          >>r.Location. X
          0

          Because r.Location returns a value type (a Point), the update to it is
          'lost'.

          By this definition Python objects (all of them) are clearly reference
          ypes and not value types.

          In .NET you can specify that a parameter to a method takes a reference
          ('out' in C# or ByRef in VB.NET). If you pass in a value type as a
          reference parameter then the .NET runtime will do boxing / unboxing
          for you.

          This means that we can write code like the following C#:

          int x = 3;
          SomeMethod(out x);

          The value of x can be changed by 'SomeMethod' and can have a different
          value - something that can't happen in Python.

          In a 'way' immutable Python types behave a bit like .NET value types,
          and mutable types like reference types. As you can see, this analogy
          breaks down.

          Michael Foord
          --
          Pedestrian accidents can happen in the blink of an eye, changing lives forever. When you're out for a stroll or crossing the street, an unexpected collision



          But ByRef is another option, and if you pass an object reference  
          ByRef, then the formal parameter is an alias for the actual parameter,  
          and assignments to it change the actual parameter.  Python doesn't  
          have this feature (nor much need for it, given its other features,  
          like tuple packing/unpacking).  So, parameter passing in ByRef is  
          clearly exactly the same as the default "ByVal" parameter passing in  
          VB.NET... as well as Java, RB, C++ (when you remember that an object  
          reference in modern languages is like a pointer in C++), and every  
          other OOP language I've looked into.
          >
          Some of those languages, like Python, don't have different modes, and  
          so the language designers had no call to give their one mode a name.  
          So let's look at those that did have such a need, like VB.NET and  
          REALbasic.  What's the default mode called?  Why, it's "ByVal".  Even  
          when that value is an object reference.  This is short for "by value"  
          -- it's not short for "by sharing" or "by object" or any other such  
          silliness.  No such terms are needed.
          >
          There are only the two cases, which Greg quite succinctly and  
          accurately described above.  One is by value, the other is by  
          reference.  Python quite clearly uses by value.  Parameters are  
          expressions that are evaluated, and the resulting value copied into  
          the formal parameter, pure and simple.  The continued attempts to  
          obfuscate this is pointless and wrong.
          >
          Best,
          - Joe

          Comment

          • Steven D'Aprano

            #50
            Re: Finding the instance reference of an object

            On Wed, 29 Oct 2008 08:27:07 -0700, Dale Roberts wrote:
            On Oct 28, 11:59 am, Joe Strout <j...@strout.ne twrote:
            >...
            >>
            >There are only the two cases, which Greg quite succinctly and
            >accurately described above.  One is by value, the other is by
            >reference.  Python quite clearly uses by value.  Parameters are
            >expressions that are evaluated, and the resulting value copied into the
            >formal parameter, pure and simple.  The continued attempts to obfuscate
            >this is pointless and wrong.
            >>
            >Best,
            >- Joe
            >
            Joe, you are being too generous and expansive here.
            >
            [Play along with me for a minute here...]
            >
            Don't you know? There is really only *ONE* case, and, you are right, it
            is Pass By Value. There is no such thing as Pass By Reference at the
            physical CPU level at all, right? If there is, show it to me. Pass By
            Reference is just a silly idiom developed by high-minded CS academics to
            confuse the rest of us. It has no practical use and should not be given
            its own name, when we already have a good an proper name for it.
            [snip]

            But Dale, you're wrong. At the physical CPU level, there's no copying of
            bits at all. If we could copy bits, then we could start with 512MB of RAM
            and say "copy all the bits" and end up with 1GB of RAM. So-called copying
            is actually just bit-flipping.

            So anyone who talks about copying parameters is talking nonsense. There
            is no "pass by value". It's all pass by bit-flipping.



            --
            Steven

            Comment

            • Joe Strout

              #51
              Re: Finding the instance reference of an object

              On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:
              You're pretty straightforward ly wrong. In Python the 'value' of a
              variable is not the reference itself.
              That's the misconception that is leading some folks around here into
              tangled nots of twisty mislogic, ultimately causing them to make up
              new terms for what every other modern language is perfectly happy
              calling Call-By-Value.

              I've thought a lot about why this misconception is so widespread here,
              and I think it must be one of the following:

              1. There was one community leader with this idea, who has been
              successful at promoting it widely, much to the detriment of all; or,

              2. Because everything in Python is an object, you're not forced to
              think clearly (and more generally) about references as values as you
              are in languages (such as Java, VB.NET, etc.) which have both simple
              types and object types.

              Either way, it's wrong (or at least, a needlessly complicated way of
              looking at things).
              .NET does draw a distinction between 'value types' and reference types
              - where using reference types are called by reference (the reference
              is passed) and value types are called by value (the value itself is
              copied).
              Quite right. Now, note that "ByRef" and "ByVal" apply to both.
              Generalize to Python. There you go.

              Best,
              - Joe

              P.S. I really am trying to quit responding to this thread. Sometimes
              the urge is too strong. But I'll keep trying!

              Comment

              • Steve Holden

                #52
                Re: Finding the instance reference of an object

                Joe Strout wrote:
                On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:
                >
                >You're pretty straightforward ly wrong. In Python the 'value' of a
                >variable is not the reference itself.
                >
                That's the misconception that is leading some folks around here into
                tangled nots of twisty mislogic, ultimately causing them to make up new
                terms for what every other modern language is perfectly happy calling
                Call-By-Value.
                >
                I tried hard to make myself believe that the above was a clever pun and
                knot [sic] a typo. Sadly I failed.
                I've thought a lot about why this misconception is so widespread here,
                and I think it must be one of the following:
                >
                1. There was one community leader with this idea, who has been
                successful at promoting it widely, much to the detriment of all; or,
                >
                2. Because everything in Python is an object, you're not forced to think
                clearly (and more generally) about references as values as you are in
                languages (such as Java, VB.NET, etc.) which have both simple types and
                object types.
                >
                How about

                3. You just hate being wrong.
                Either way, it's wrong (or at least, a needlessly complicated way of
                looking at things).
                >
                One that has apparently served for almost twenty years now.
                >.NET does draw a distinction between 'value types' and reference types
                >- where using reference types are called by reference (the reference
                >is passed) and value types are called by value (the value itself is
                >copied).
                >
                Quite right. Now, note that "ByRef" and "ByVal" apply to both.
                Generalize to Python. There you go.
                >
                Best,
                - Joe
                >
                P.S. I really am trying to quit responding to this thread. Sometimes
                the urge is too strong. But I'll keep trying!
                >
                We must tax your patience dreadfully. I have suffered from the same
                myself, but I fear we are doomed to pursue each other until Godwin's law
                releases us.

                Which reminds me, had you thought about submitting a paper along these
                lines to PyCon? If we meet at PyCon at least let me buy you a pint to
                show there are no hard feelings.

                regards
                Steve
                --
                Steve Holden +1 571 484 6266 +1 800 494 3119
                Holden Web LLC http://www.holdenweb.com/

                Comment

                • Fuzzyman

                  #53
                  Re: Finding the instance reference of an object

                  On Oct 30, 1:13 am, Joe Strout <j...@strout.ne twrote:
                  On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:
                  >
                  You're pretty straightforward ly wrong. In Python the 'value' of a
                  variable is not the reference itself.
                  >
                  That's the misconception that is leading some folks around here into
                  tangled nots of twisty mislogic, ultimately causing them to make up
                  new terms for what every other modern language is perfectly happy
                  calling Call-By-Value.
                  >
                  I've thought a lot about why this misconception is so widespread here,
                  and I think it must be one of the following:
                  >
                  1. There was one community leader with this idea, who has been
                  successful at promoting it widely, much to the detriment of all; or,
                  >
                  2. Because everything in Python is an object, you're not forced to
                  think clearly (and more generally) about references as values as you
                  are in languages (such as Java, VB.NET, etc.) which have both simple
                  types and object types.
                  >

                  But those languages clearly make the distinction between values and
                  references that you refuse to make! Go figure...

                  Michael
                  Either way, it's wrong (or at least, a needlessly complicated way of
                  looking at things).
                  >
                  .NET does draw a distinction between 'value types' and reference types
                  - where using reference types are called by reference (the reference
                  is passed) and value types are called by value (the value itself is
                  copied).
                  >
                  Quite right. Now, note that "ByRef" and "ByVal" apply to both.
                  Generalize to Python. There you go.
                  >
                  Best,
                  - Joe
                  >
                  P.S. I really am trying to quit responding to this thread. Sometimes
                  the urge is too strong. But I'll keep trying!

                  Comment

                  • Fuzzyman

                    #54
                    Re: Finding the instance reference of an object

                    On Oct 30, 1:13 am, Joe Strout <j...@strout.ne twrote:
                    On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:
                    >
                    You're pretty straightforward ly wrong. In Python the 'value' of a
                    variable is not the reference itself.
                    >
                    That's the misconception that is leading some folks around here into
                    tangled nots of twisty mislogic, ultimately causing them to make up
                    new terms for what every other modern language is perfectly happy
                    calling Call-By-Value.
                    >
                    I've thought a lot about why this misconception is so widespread here,
                    and I think it must be one of the following:
                    >
                    1. There was one community leader with this idea, who has been
                    successful at promoting it widely, much to the detriment of all; or,
                    >
                    2. Because everything in Python is an object, you're not forced to
                    think clearly (and more generally) about references as values as you
                    are in languages (such as Java, VB.NET, etc.) which have both simple
                    types and object types.
                    >

                    To make it clearer for you, call by value means that the value is
                    copied in - and therefore changes to the value won't be visible to the
                    caller.

                    In .NET this is true of mutable value types - changes made are made to
                    a copy and not visible to the caller. In Python we *only* have
                    reference types, so changes to *any* mutable object are visible to the
                    caller.

                    In .NET you can call by reference with a value type - and the runtime
                    does boxing for you so that you can see the changes. You have to
                    explicitly ask for call by reference though.

                    Michael
                    Either way, it's wrong (or at least, a needlessly complicated way of
                    looking at things).
                    >
                    .NET does draw a distinction between 'value types' and reference types
                    - where using reference types are called by reference (the reference
                    is passed) and value types are called by value (the value itself is
                    copied).
                    >
                    Quite right. Now, note that "ByRef" and "ByVal" apply to both.
                    Generalize to Python. There you go.
                    >
                    Best,
                    - Joe
                    >
                    P.S. I really am trying to quit responding to this thread. Sometimes
                    the urge is too strong. But I'll keep trying!

                    Comment

                    • Dale Roberts

                      #55
                      Re: Finding the instance reference of an object

                      On Oct 29, 9:13 pm, Joe Strout <j...@strout.ne twrote:
                      On Oct 29, 2008, at 4:52 PM, Fuzzyman wrote:
                      >
                      You're pretty straightforward ly wrong. In Python the 'value' of a
                      variable is not the reference itself.
                      >
                      That's the misconception that is leading some folks around here into  
                      tangled nots of twisty mislogic, ultimately causing them to make up  
                      new terms for what every other modern language is perfectly happy  
                      calling Call-By-Value.
                      Doesn't this logic also apply to Call By Reference? Isn't that term
                      redundant too? (see my 3 C++ examples above). If not, why not? Are you
                      saying that C++ is capable of using the Call By Reference idiom, but C
                      is not, because C does not have a reference designation for formal
                      function parameters?

                      "Call By Object Reference" is an idiom, just like Call By Reference.
                      It is not a physical description of what is going on internally at the
                      register/stack level (which is always just shuffling values around -
                      or flipping bits, as Steven points out), it is a higher level concept
                      that helps people understand the *intention* (not necessarily the
                      implementation) of the mechanism.

                      You cannot look a C++ programmer straight in the eye and say that
                      "Python uses Call By Value, Period", without also informing them that
                      "Python variables can ONLY EVER hold object references - that is the
                      only "value" they can ever hold". Then the C++ programmer will go "Oh,
                      yea, that makes sense".

                      Instead of having to say all of that, we just give it a new name.
                      Instead of "Call By Value, Where Every Single Value Is Only Ever A
                      Reference To An Object Which Contains The Actual Value That
                      Programmers Usually Refer To", we just say "Call By Object Reference".
                      ...
                      2. Because everything in Python is an object, you're not forced to  
                      think clearly (and more generally) about references as values
                      I think we've shown that we are all in fact thinking clearly about it,
                      and we all (you included, of course!) understand what is going on.
                      It's just a matter of what words we choose to describe it.

                      Using your definition of value, though, I believe that if you want to
                      throw out Call By Object Reference, you also have to throw out Call By
                      Reference. See my 3 C++ examples above. And just for fun I did look at
                      the assembler output, and, indeed, the output for examples 1 and 3 is
                      absolutely identical. They are the same thing, as far as the CPU is
                      concerned.

                      Would you give them different names?

                      dale

                      Comment

                      • Joe Strout

                        #56
                        Re: Finding the instance reference of an object

                        On Oct 30, 2008, at 7:56 AM, Dale Roberts wrote:
                        >That's the misconception that is leading some folks around here into
                        >tangled nots of twisty mislogic, ultimately causing them to make up
                        >new terms for what every other modern language is perfectly happy
                        >calling Call-By-Value.
                        >
                        Doesn't this logic also apply to Call By Reference? Isn't that term
                        redundant too? (see my 3 C++ examples above). If not, why not?
                        It's not. Wikipedia explains the difference pretty well.
                        Are you saying that C++ is capable of using the Call By Reference
                        idiom,
                        but C is not, because C does not have a reference designation for
                        formal
                        function parameters?
                        It's been a LONG time since I did anything in C, but yes, I believe
                        that reference parameters were an addition that came with C++.
                        "Call By Object Reference" is an idiom, just like Call By Reference.
                        It is not a physical description of what is going on internally at the
                        register/stack level (which is always just shuffling values around -
                        or flipping bits, as Steven points out), it is a higher level concept
                        that helps people understand the *intention* (not necessarily the
                        implementation) of the mechanism.
                        Right. And you can easily tell the difference, by whether an
                        assignment to the formal parameter causes any change to the actual
                        parameter that was passed in. If it does, that's call-by-reference.
                        If it doesn't, it's call-by-value. In Python, it doesn't. In VB.NET
                        (and relatives), it doesn't if the parameter is declared (explicitly
                        or implicitly) "ByVal", and does if it's declared "ByRef". (Whether
                        the parameter is a reference type or a simple value type makes no
                        difference.)

                        Python's behavior is exactly and always equivalent to the "ByVal"
                        behavior of languages that have both behaviors. It also matches the
                        definition of call-by-value. I quite agree that it's not helpful to
                        delve into the physical flipping of transistor states. We're talking
                        about the behavior, and the behavior, very clearly, is call-by-value.
                        To call it something else only clouds the issue and results in
                        confusion. (Perhaps explaining why there appears to be far more
                        confusion about call semantics in the Python community than in the
                        community of other languages where the default semantics are exactly
                        the same.)

                        Best,
                        - Joe


                        Comment

                        • Dale Roberts

                          #57
                          Re: Finding the instance reference of an object

                          On Oct 30, 11:03 am, Joe Strout <j...@strout.ne twrote:
                          ...
                          >Are you saying that C++ is capable of using the Call By Reference idiom,
                          >but C is not, because C does not have a reference designation for formal
                          >function parameters?
                          >
                          It's been a LONG time since I did anything in C, but yes, I believe  
                          that reference parameters were an addition that came with C++.
                          Okay, I completely understand you, and I think we will just have to
                          agree to disagree about the best term to use for Python's parameter
                          passing mechanism, and this will likely be my concluding post on this
                          topic (although I have enjoyed it very much and have solidified my own
                          understanding).

                          I even found a few web sites that very strongly support your viewpoint
                          (as it relates to Java):





                          The difference is that I would say that C supports the Pass By
                          Reference idiom using this syntax:

                          myfunc(int *val){} /*CALL:*/ myfunc(&i);

                          which actually passes an address expression (not a variable) by value,
                          but "looks and feels" like a reference to the "i" variable, which
                          contains the real value that we care about - and allows modification
                          of that value.

                          C++ adds a syntactic change for this very commonly used C idiom, but
                          does not add any new capability - the results are absolutely
                          indistinguishab le.

                          Python, likewise, in relation to the values we care about (the values
                          contained only in objects, never in variables) behaves like Call by
                          Object Reference.

                          If I tell someone that Python uses only Call By Value (and that is all
                          I tell them), they may come away with the impression that variables
                          contain the values they care about, and/or that the contents of
                          objects are copied, neither of which is the case, even for so-called
                          "simple", immutable objects (indeed, at the start of this thread, you
                          said you believed that, like Java, simple values were contained within
                          Python variables).

                          But Python, unlike Java or most other commonly used languages, can
                          ONLY EVER pass an object reference, and never an actual value I care
                          about, and I think that idiom deserves a different name which
                          distinguishes it from the commonly accepted notion of Pass By Value.

                          Thanks for a thoughtful discussion,
                          dale

                          Comment

                          • Dale Roberts

                            #58
                            Re: Finding the instance reference of an object

                            On Oct 30, 3:06 pm, Dale Roberts <goobe...@gmail .comwrote:
                            ... that idiom deserves a different name which
                            distinguishes it from the commonly accepted notion of Pass By Value.
                            Bah, what I meant to end with was:

                            Just as the Pass By Reference idiom deserves a unique name to
                            distinguish it from Pass By Value (even though it is often Pass By
                            (address) Value internally), so Pass By Object Reference deserves a
                            unique name (even though it too is Pass By (reference) Value
                            internally).

                            Again, thanks for the discussion,
                            dale

                            Comment

                            • greg

                              #59
                              Re: Finding the instance reference of an object

                              Douglas Alan wrote:
                              greg <greg@cosc.cant erbury.ac.nzwri tes:
                              >
                              >>Seems to me that (1) describes exactly how parameter passing
                              >>works in Python. So why insist that it's *not* call by value?
                              >
                              Because there's an important distinction to be made,
                              The distinction isn't about parameter passing, though, it's
                              about the semantics of *assignment*. Once you understand
                              how assigment works in Python, all you need to know then
                              is that parameters are passed by assigning the actual
                              parameter to the formal parameter. All else follows from
                              that.

                              This holds for *all* languages that I know about, both
                              static and dynamic. Once you know how assignment works in
                              the language concerned, then you know how parameter
                              passing works as well. There is no need for new terms.
                              and the
                              distinction has been written up in the Computer Science literature
                              since Lisp first starting using the same argument passing semantics as
                              Python back in 1958. The semantics are called "call by sharing".
                              I still think it's an unnecessary term, resulting from
                              confusion on the part of the authors about the meanings of
                              the existing terms.

                              If there's any need for a new term, it would be "assignment
                              by sharing". Although there's already a term in use for that,
                              too -- it's known as reference assignment.
                              Many mainstream programming languages other than Python now use call
                              by sharing. They include Java, JavaScript, Ruby, ActionScript, and C#.
                              I would say they use assignment by sharing, and call by
                              value.

                              --
                              Greg

                              Comment

                              • greg

                                #60
                                Re: Finding the instance reference of an object

                                Gabriel Genellina wrote:
                                En Tue, 28 Oct 2008 00:58:10 -0200, greg <greg@cosc.cant erbury.ac.nz>
                                escribió:
                                >
                                >(1) Call by value: The actual parameter is an expression. It is
                                > evaluated and the result is assigned to the formal parameter.
                                > Subsequent assignments to the formal parameter do not affect
                                > the actual parameter.
                                >>
                                >(2) Call by reference: The actual parameter is an lvalue. The
                                > formal parameter becomes an alias for the actual parameter,
                                > so that assigning to the formal parameter has the same
                                > effect as assigning to the actual parameter.
                                >
                                Those definitions are only applicable to unstructured, primitive types,
                                where the only relevant operations are "get value" and "assign value".
                                Structured types provide other operations too - like selection
                                (attribute get/set in Python).
                                But that isn't what "assigning to the formal parameter" means --
                                it only means assigning directly to the parameter *name*.
                                It is unspecified on both definitions
                                above what happens in those cases.
                                That's true, but it's outside the scope of the parameter passing
                                mechanism to define what happens in those cases. That's down to
                                the data model being used by the language and the semantics of
                                assignment in general.

                                --
                                Greg

                                Comment

                                Working...