[Tutor] R: Re: Re: Re: Class learning
cs at zip.com.au
Sat Jan 24 12:32:31 CET 2015
On 24Jan2015 09:16, Alan Gauld <alan.gauld at btinternet.com> wrote:
>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.
However, Python is an "open Kimono" language; direct access to object
attributes is permitted and, with restraint, encouraged what appropriate. EVen
the leading underscore convention for "private" attributes is just a naming
The point here is that while you _can_ program in a pure OOP fashion, using
only method calls, the language does not enforce this. Since OOP is just a
particular paradigm, this is a good thing: one can choose to work that way or
you can choose not to, or you can mix at your discretion.
>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.
In a "pure" OOP environment yes. But this needn't be.
>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.
There is a flip side to that. In a language like Python or Java, every entity
is an object. Including mere containers. If the only medium for interacting
with a contained is a message in the form of a method call, things get very
painful very fast.
So there is a line to be drawn, several in fact.
For notational convenience, a property is worthwhile all on its own: it
presents succinct access to object messages that retrieve or set an aspect of a
And for containers, again you have a choice. You can permit direct access to
container members as ordinary attributes, or you can require cumbersome method
access and some kind of (perhaps implicit) mapping from method names to the
private container member attributes.
While you see a property as a hack, I view it as a succinct way to provide
method mediated access to an attribute with the benefits that can accompany it:
programmed behaviour around the access or setting, or simple abstraction,
separating the published name of the property from whatever object internals
are used in its implementation.
>>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
>>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.
OOP is a tool to an end. It is a very expressive and powerful discipline giving
you good data separation. But it isn't the only tool, and it isn't always the
>>My intuition is that a function is costly (potentially) and that
>>consulting an attribute is very cheap. I don't want to break such
>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. [...]
Here you have missed my point.
I am not referring to the overhead of making a function call, but the intuitive
cost that distinguishes something one thinks of as an attribute from something
one thinks of as a function: a function may entain an arbitrary amount of work
whereas an attibute is almost free, and constant in cost.
I'm not talking about optimisation here, I'm talking about the notion of a
value that is derived from (unspecified and perhaps costly) computation versus
a value that is merely stored, and trivially retrieved.
The an attribute/method/function very closely resembles the latter, I am prone
to make it into a property.
Cameron Simpson <cs at zip.com.au>
... you could spend *all day* customizing the title bar. Believe me. I
speak from experience. - Matt Welsh
More information about the Tutor