[Tutor] R: Re: Re: Re: Class learning

[Alan Gauld]

On 24/01/15 01:50, Cameron Simpson wrote:
> On 24Jan2015 00:47, Alan Gauld <alan.gauld at btinternet.com> wrote:

>> But why a property rather than a simple method?

> Because it is a value that feels like an attribute.

OK, Having seen Dannys reply as well as yours I guess I see the logic.
I think Python's openness has lead ton this problem of breaking the 
basic OOP model. The whole concept of OOP is that objects communicate 
via messages. Direct access to the internals should be discouraged.
So the default mechanism should be a message which in Python is 
represented by a method call.

But Python has traditionally allowed direct access to data which
has encouraged a style of programming that forgets that objects
are not *supposed* to be directly accessed. That leads to a kind of 
mentality that treats objects as mere containers rather than as active 
subprograms, In that frame of reference properties sound like a good 
thing even though they break the fundamental theoretical OOP model.

The problem I have with properties is that they are fundamentally
a way of "fixing" a broken model. We have allowed people to mix
direct access and message calling then bolted on a way to convert the 
direct access into a method call. Its pragmatic but not conducive to 
fixing the underlying issue. Future incarnations of the classes involved 
are likely to promulgate the direct access approach.

> A method that always returns the same value for a given object (and is
> very cheap) is, to my mind, not worth burdening the caller with the
> detail that is it a function.

There is the problem. When using objects we shouldn't be thinking that 
we are calling a function we should be thinking we are sending a 
message. The message may look like a kind of function call but 
conceptually its very different. We are instructing an independent 
computing entity (the object) to perform some task on our behalf. The 
object may be a part of our programs computing environment or it could 
be on another processor or even on another network node, we shouldn't care.

> the caller bothers keeping the value around) then why should the caller
> care that it is a function? So why should it even look like a function?

Because they should remember that they are dealing with an object not 
just a data container. It encourages the client (and designer) to treat 
the object as a separate "living" entity within the program.

> It should look and feel like any other object attribute - a simple value
> that can just be examined.

But that's a broken object model. It's a concession Python makes
for pragmatic reasons. Unfortunately we, as Python programmers, are
starting to abuse that freedom and forget the fundamentals of OOP.
Our programs become more brittle because of it and we need
to introduce "fixes" like properties to tidy up the mess.

> My intuition is that a function is costly (potentially) and that
> consulting an attribute is very cheap.  I don't want to break such
> intuition.

That's true, there is a small overhead in calling a function
but  considering that aspect in the OOP design stage is always
a premature optimisation. Bad OOP design that encourages direct
access to data for processing outside the object is far more
likely to lead to performance issues.

Of course pure OOP design is often not practical (or even possible)
and very occasionally we do need to consider the performance impact of a 
function call, but those occasions are as rare as hens teeth in
most real world programs, there are usually far bigger factors to consider.


-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos