On 24Jan2015 09:16, Alan Gauld <[email protected]> wrote:
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.
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
convention.
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
message.
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
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.
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
preferred choice.
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. [...]
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.
Cheers,
Cameron Simpson <[email protected]>
... you could spend *all day* customizing the title bar. Believe me. I
speak from experience. - Matt Welsh
_______________________________________________
Tutor maillist - [email protected]
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
