class methods vs. functions

[Jacek Generowicz]

On 15 Jul 2004, at 18:00, Egbert Bouwman wrote:

> On Thu, Jul 15, 2004 at 02:10:06PM +0200, Jacek Generowicz wrote:
>
>> Why treat it as private, if it isn't marked as private? If it isn't
>> marked as private, then it's part of the interface. If it's part of
>> the interface, then it is intended for use by clients. If it's
>> intended for use by clients, then use it.
>
> My impression is that you can hardly call this OOO:
> Object Oriented Orthodoxy. For instance, from the GOF I learned:

Aaah, the dear GOF book. You do realize that the GOF book is, to a 
lange extent, a book about the shortcomings of C++, don't you?

For example, think about how you would implement the Decorator and the 
State patterns in Python.

I would advise against basing your understanding of what object 
oriented programming is about, on the GOF book.

> - the object's internal state can not be accessed directly

This is blatantly false, as your code snippet below clearly 
demonstrates. (You probably meant "should not" rather that "can not". 
The "should not" is a dogma. Understand its motivation, and decide for 
yourself to what extent you want to buy it.)

> - operations are the only way to change an object's internal state

Ditto. (... "are the only way"  -> "should be the only way" ...)

> - requests (or messages) are the only way to get an object
>   to execute an operation

Read up about properties in Python.

Strictly speaking, it's not an object which executes an operation; 
rather methods carry out operations on objects. And it's certainly not 
true that messages are the only way to get a method to carry out an 
operation on objects ... put differently: generic functions exist.

> It is not easy to find definitions of 'interface' in python books,

How about "Anything that does not start with an underscore" ?

(One can argue about the details of this proto-definition, but in terms 
of value per word, it's pretty good, I'd say.)

> And now you suggest that everything that is accessible is part
> of the interface.

No. I suggest that everything that is part of the interface is part of 
the interface. Put in other terms, everything that is not marked as 
private, is part of the interface (or in some languages, everything 
that is marked as public, is part of the interface --- though "private" 
and "public" might not be the words which are used to describe a 
similar concept in those languages). Some languages (notably C++ and 
Java) consider that marking things as private is not good enough (I 
guess that the assumption is that people who program in those languages 
are too stupid to understand the importance of interfaces and to 
respect them), and such languages attempt to make the private parts 
inaccessible.

Encapsulation and access restriction are orthogonal concepts, which 
have been conflated in Java and C++. That doesn't make them any less 
orthogonal, as concepts ... so don't make the (all too common mistake) 
of believing that they are actually one and the same.

>  I think I prefer the orthodoxy.

Into bondage, are you ? :-)

> I suppose that is what you mean when you say:
>> Be careful not to let Java or C++ (or anyone strongly influenced by
>> them) to shape your understanding of object oriented programming. You
>> would be doing yourself a disservice.
> but I need more explanations, arguments, references.

Well, in terms of explanations and arguments, I was steering you 
towards a discussion of the generic-function OO paradigm ... but you 
seem not to have followed that up.

In terms of references ... try looking into some languages which 
support OO, which predate Java and C++ (or which are otherwise not 
influenced by them, or, at least, look very different from them.) You 
could try Smalltalk, or Common Lisp, for example.

> You seem to encourage the following practice:
>>>> class C: pass
>>>> c = C()
>>>> c.x = 9

Absolutely.

> the internal state of c is not private,

This is not generally true, but it is true in this case.

For example, I would discourage the following:

class C:
     def __init__(self):
         self._x = 3

c = C()
c._x = 9

Note that I would not forbid it. In fact, I would encourage it, in some 
situations. For example

a) You are debugging your application, or investigating its behaviour

b) The author of C hadn't anticipated some perfectly valid use you wish 
to make of C, and didn't provide you with an adequate interface