Re: Not fully OO ?

[Kay Schluehr]

On 20 Sep., 18:33, Bruno Desthuilliers
<[e-mail]:

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...

[Aaron \Castironpi\ Brady]

On Sep 20, 3:22*pm, Kay Schluehr <[e-mail]:

On 20 Sep., 18:33, Bruno Desthuilliers

<[e-mail]:

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.

[Christian Heimes]

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

[Aaron \Castironpi\ Brady]

On Sep 20, 8:06*pm, Christian Heimes <[e-mail]:

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

[Kay Schluehr]

On 20 Sep., 23:07, "Aaron \"Castironpi\" Brady" <[e-mail]>
wrote:

On Sep 20, 3:22 pm, Kay Schluehr <[e-mail]:

On 20 Sep., 18:33, Bruno Desthuilliers

<[e-mail]:

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.

[=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?=]

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

[Fredrik Lundh]

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>

[=?ISO-8859-1?Q?Ricardo_Ar=E1oz?=]

Kay Schluehr wrote:

On 20 Sep., 23:07, "Aaron \"Castironpi\" Brady" <[e-mail]>
wrote:

>On Sep 20, 3:22 pm, Kay Schluehr <[e-mail]:

>>On 20 Sep., 18:33, Bruno Desthuilliers
<[e-mail]:
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.

x.__len__()