Re: Not fully OO ?

Collapse
This topic is closed.
X
X
Collapse
 
  • Page of 1
  • Time
  • Show
Clear All
new posts
Previous template Next
  • Kay Schluehr
    #1

    Re: Not fully OO ?

    On 20 Sep., 18:33, Bruno Desthuilliers
    <bdesth.quelque ch...@free.quel quepart.frwrote :
    The following definitions are AFAIK the only commonly accepted
    definitions about OO:
    >
    1/ an object is defined by identity, state and behaviour
    2/ objects interacts by sending messages each other
    3/ an OO program is made of interacting objects
    >
    I let you find out whether Python meets these 3 definitions - and if
    Java does (hint : in Python, everything you can bind to a name is an
    object - this is not true in Java or C++).
    This is correct but it detracts from a more general problem of
    language "paradigms" .

    Assume you type
    >>2+2
    4

    Now you are free to interpret this as a simple, primitive arithmetic
    operation but you can also claim that 2 sends an __add__ message to 2.
    Hereby the state of the 2 objects are not altered but a new 4 object
    is created. OO babble is more impressive isn't it?

    Actually it is simply wrong in the mentioned case and here is the
    proof:

    def foo():
    return 2+2

    import dis
    dis.dis(foo)

    2 0 LOAD_CONST 2 (4)
    3 RETURN_VALUE

    OO is a heuristic method used to understand the semantics of a
    programming language. It can also inspire language design but as
    you've rightly said: jugde yourself and see how far you get with it.

    Applying OO on interpreter level is by no means a sign of a high
    quality implementation whereas structuring programs in the large will
    likely benefit from class based organization and encapsulation. Of
    course one can also reverse the value hierarchy and find perverse joy
    in having a pure OO language but apply monkey patching everywhere. I
    suppose you know which language I'm talking about...
    Tags: None
    • Aaron \Castironpi\ Brady
      #2
      Re: Not fully OO ?

      On Sep 20, 3:22 pm, Kay Schluehr <kay.schlu...@g mx.netwrote:
      On 20 Sep., 18:33, Bruno Desthuilliers
      >
      <bdesth.quelque ch...@free.quel quepart.frwrote :
      The following definitions are AFAIK the only commonly accepted
      definitions about OO:
      >
      1/ an object is defined by identity, state and behaviour
      2/ objects interacts by sending messages each other
      3/ an OO program is made of interacting objects
      >
      I let you find out whether Python meets these 3 definitions - and if
      Java does (hint : in Python, everything you can bind to a name is an
      object - this is not true in Java or C++).
      >
      This is correct but it detracts from a more general problem of
      language "paradigms" .
      >
      Assume you type
      >
      >2+2
      >
      4
      >
      Now you are free to interpret this as a simple, primitive arithmetic
      operation but you can also claim that 2 sends an __add__ message to 2.
      Hereby the state of the 2 objects are not altered but a new 4 object
      is created. OO babble is more impressive isn't it?
      >
      Actually it is simply wrong in the mentioned case and here is the
      proof:
      >
      def foo():
          return 2+2
      >
      import dis
      dis.dis(foo)
      >
        2           0 LOAD_CONST               2 (4)
                    3 RETURN_VALUE
      >
      OO is a heuristic method used to understand the semantics of a
      programming language. It can also inspire language design but as
      you've rightly said: jugde yourself and see how far you get with it.
      >
      Applying OO on interpreter level is by no means a sign of a high
      quality implementation whereas structuring programs in the large will
      likely benefit from class based organization and encapsulation. Of
      course one can also reverse the value hierarchy and find perverse joy
      in having a pure OO language but apply monkey patching everywhere. I
      suppose you know which language I'm talking about...
      It sounds like you think that you -can- write OO programs in Python,
      but you don't have to. I agree.

        Comment

        • Christian Heimes
          #3
          Re: Not fully OO ?

          Kay Schluehr wrote:
          Actually it is simply wrong in the mentioned case and here is the
          proof:
          >
          def foo():
          return 2+2
          >
          import dis
          dis.dis(foo)
          >
          2 0 LOAD_CONST 2 (4)
          3 RETURN_VALUE
          >
          OO is a heuristic method used to understand the semantics of a
          programming language. It can also inspire language design but as
          you've rightly said: jugde yourself and see how far you get with it.
          It's not wrong. You have found a simple optimization. Lot's of compilers
          for lots of languages optimize code by code folding.

          Python's peephole optimizer replaces code like 2+2 with 4.

          Christian

            Comment

            • Aaron \Castironpi\ Brady
              #4
              Re: Not fully OO ?

              On Sep 20, 8:06 pm, Christian Heimes <li...@cheimes. dewrote:
              Kay Schluehr wrote:
              Actually it is simply wrong in the mentioned case and here is the
              proof:
              >
              def foo():
                  return 2+2
              >
              import dis
              dis.dis(foo)
              >
                2           0 LOAD_CONST               2 (4)
                            3 RETURN_VALUE
              >
              OO is a heuristic method used to understand the semantics of a
              programming language. It can also inspire language design but as
              you've rightly said: jugde yourself and see how far you get with it.
              >
              It's not wrong.
              The meaning of the Python program is, internally, on a cycle-by-cycle
              basis, "Object 2; send add( Object 2 ) to Object 2; Return object 4."

              CPython doesn't do this, but due to the fact that there are no cases
              in which that distinction affects the output, it's still an
              implementation of Python.

              Or at least, a practical implementation.
              You have found a simple optimization. Lot's of compilers
              for lots of languages optimize code by code folding.
              >
              Python's peephole optimizer replaces code like 2+2 with 4.
              >
              Christian

                Comment

                • Kay Schluehr
                  #5
                  Re: Not fully OO ?

                  On 20 Sep., 23:07, "Aaron \"Castironpi \" Brady" <castiro...@gma il.com>
                  wrote:
                  On Sep 20, 3:22 pm, Kay Schluehr <kay.schlu...@g mx.netwrote:
                  >
                  >
                  >
                  On 20 Sep., 18:33, Bruno Desthuilliers
                  >
                  <bdesth.quelque ch...@free.quel quepart.frwrote :
                  The following definitions are AFAIK the only commonly accepted
                  definitions about OO:
                  >
                  1/ an object is defined by identity, state and behaviour
                  2/ objects interacts by sending messages each other
                  3/ an OO program is made of interacting objects
                  >
                  I let you find out whether Python meets these 3 definitions - and if
                  Java does (hint : in Python, everything you can bind to a name is an
                  object - this is not true in Java or C++).
                  >
                  This is correct but it detracts from a more general problem of
                  language "paradigms" .
                  >
                  Assume you type
                  >
                  >>2+2
                  >
                  4
                  >
                  Now you are free to interpret this as a simple, primitive arithmetic
                  operation but you can also claim that 2 sends an __add__ message to 2.
                  Hereby the state of the 2 objects are not altered but a new 4 object
                  is created. OO babble is more impressive isn't it?
                  >
                  Actually it is simply wrong in the mentioned case and here is the
                  proof:
                  >
                  def foo():
                  return 2+2
                  >
                  import dis
                  dis.dis(foo)
                  >
                  2 0 LOAD_CONST 2 (4)
                  3 RETURN_VALUE
                  >
                  OO is a heuristic method used to understand the semantics of a
                  programming language. It can also inspire language design but as
                  you've rightly said: jugde yourself and see how far you get with it.
                  >
                  Applying OO on interpreter level is by no means a sign of a high
                  quality implementation whereas structuring programs in the large will
                  likely benefit from class based organization and encapsulation. Of
                  course one can also reverse the value hierarchy and find perverse joy
                  in having a pure OO language but apply monkey patching everywhere. I
                  suppose you know which language I'm talking about...
                  >
                  It sounds like you think that you -can- write OO programs in Python,
                  but you don't have to. I agree.
                  The whole point of OO is providing high level ( system level ) not low
                  level ( interpreter level ) semantics. Partitioning a system into
                  isolated and communicating objects is a strong and important metaphor.
                  Recently there were some comments on the web that mentioned Erlang to
                  be pretty much OO in this respect although Erlang is functional and
                  has no base level notion of an "object". It's even well known that Joe
                  Armstrong holds low opinions about the entire object business.

                  Notice that I believe that the popular meme that OO is "bolted on"
                  Python has little if nothing to do with OO itself but with API
                  consistency. When people have to type len(x) instead of x.len() this
                  breaks their expectations on how the language has to behave.

                    Comment

                    • =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=
                      #6
                      Re: Not fully OO ?

                      Christian Heimes wrote:
                      Kay Schluehr wrote:
                      >Actually it is simply wrong in the mentioned case
                      [...]
                      >
                      It's not wrong. You have found a simple optimization. Lot's of compilers
                      for lots of languages optimize code by code folding.
                      I don't think he meant that Python is wrong somehow, but that the OO
                      babble of what happens for 2+2 is wrong. The babble said that, when the
                      code is executed, an __add__ message is sent to the 2 object, with
                      another 2 object as the parameter. That statement is incorrect: no
                      message is sent at all, but the result is available even before the
                      program starts.

                      FWIW, "2+2" is not a good case for OO in Smalltalk, either. In a typical
                      implementation, SmallInteger is not a real class, in the sense that 2 is
                      not a real object. Instead, it lives in a tagged pointer, i.e. it has no
                      identity.

                      Regards,
                      Martin

                        Comment

                        • Fredrik Lundh
                          #7
                          Re: Not fully OO ?

                          Martin v. Löwis wrote:
                          I don't think he meant that Python is wrong somehow, but that the OO
                          babble of what happens for 2+2 is wrong. The babble said that, when the
                          code is executed, an __add__ message is sent to the 2 object, with
                          another 2 object as the parameter. That statement is incorrect: no
                          message is sent at all, but the result is available even before the
                          program starts.
                          On the other hand, the inability to distinguish between "as if" and
                          "hah, I've looked under the covers" isn't necessarily a good trait for a
                          programmer. If he bases his mental model on concrete implementation
                          details of a production quality software product, he's bound to end up
                          with a cargo-cultish understanding of fundamental issues. If he uses it
                          to win arguments, people will flip his bozo bit pretty quickly.

                          </F>

                            Comment

                            • =?ISO-8859-1?Q?Ricardo_Ar=E1oz?=
                              #8
                              Re: Not fully OO ?

                              Kay Schluehr wrote:
                              On 20 Sep., 23:07, "Aaron \"Castironpi \" Brady" <castiro...@gma il.com>
                              wrote:
                              >On Sep 20, 3:22 pm, Kay Schluehr <kay.schlu...@g mx.netwrote:
                              >>
                              >>
                              >>
                              >>On 20 Sep., 18:33, Bruno Desthuilliers
                              >><bdesth.quelq uech...@free.qu elquepart.frwro te:
                              >>>The following definitions are AFAIK the only commonly accepted
                              >>>definition s about OO:
                              >>>1/ an object is defined by identity, state and behaviour
                              >>>2/ objects interacts by sending messages each other
                              >>>3/ an OO program is made of interacting objects
                              >>>I let you find out whether Python meets these 3 definitions - and if
                              >>>Java does (hint : in Python, everything you can bind to a name is an
                              >>>object - this is not true in Java or C++).
                              >>This is correct but it detracts from a more general problem of
                              >>language "paradigms" .
                              >>Assume you type
                              >>>>>2+2
                              >>4
                              >>Now you are free to interpret this as a simple, primitive arithmetic
                              >>operation but you can also claim that 2 sends an __add__ message to 2.
                              >>Hereby the state of the 2 objects are not altered but a new 4 object
                              >>is created. OO babble is more impressive isn't it?
                              >>Actually it is simply wrong in the mentioned case and here is the
                              >>proof:
                              >>def foo():
                              >> return 2+2
                              >>import dis
                              >>dis.dis(foo )
                              >> 2 0 LOAD_CONST 2 (4)
                              >> 3 RETURN_VALUE
                              >>OO is a heuristic method used to understand the semantics of a
                              >>programming language. It can also inspire language design but as
                              >>you've rightly said: jugde yourself and see how far you get with it.
                              >>Applying OO on interpreter level is by no means a sign of a high
                              >>quality implementation whereas structuring programs in the large will
                              >>likely benefit from class based organization and encapsulation. Of
                              >>course one can also reverse the value hierarchy and find perverse joy
                              >>in having a pure OO language but apply monkey patching everywhere. I
                              >>suppose you know which language I'm talking about...
                              >It sounds like you think that you -can- write OO programs in Python,
                              >but you don't have to. I agree.
                              >
                              The whole point of OO is providing high level ( system level ) not low
                              level ( interpreter level ) semantics. Partitioning a system into
                              isolated and communicating objects is a strong and important metaphor.
                              Recently there were some comments on the web that mentioned Erlang to
                              be pretty much OO in this respect although Erlang is functional and
                              has no base level notion of an "object". It's even well known that Joe
                              Armstrong holds low opinions about the entire object business.
                              >
                              Notice that I believe that the popular meme that OO is "bolted on"
                              Python has little if nothing to do with OO itself but with API
                              consistency. When people have to type len(x) instead of x.len() this
                              breaks their expectations on how the language has to behave.
                              x.__len__()




                                Comment

                                Previous template Next
                                Working...