On 24/01/15 01:50, Cameron Simpson wrote:
On 24Jan2015 00:47, Alan Gauld <[email protected]> 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
_______________________________________________
Tutor maillist - [email protected]
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
