classes (was Re: Same again please for OOP)
erno-news at erno.iki.fi
Mon Dec 25 10:34:48 EST 2000
>>>>> "Alex" == Alex Martelli <aleaxit at yahoo.com> writes:
|| i don't understand what is wrong with this - i like making them all
|| methods, so i don't have to remember if it's an attribute or method
|| later. also overrinding __getattr__ later, if it turns out to be
|| needed, is tedious and ugly.
| "Tedious and ugly"?! Just add inheritance from the usual mixin:
| class AccessorsMixin:
| def __getattr__(self, name):
| if name.startswith('__'): raise AttributeError,name
| return getattr(self, '__get_'+name)()
you forgot __setattr__, it's more fun.
but ok, after these, it's merely ugly :). tastes too much like
operator overloading to me.
| and implement method __get_location(self) the same way as you'd
| implement location(self) in your style. What could be easier? If
| you already have a __getattr__, it's equally OK to add this couple
| of lines to it, or delegate to this one (delegating has pluses).
| Giving accessor methods uniform names is hardly a minus, and
| starting them with something suggesting 'get' is particularly good.
even easier than __get_location(self) is get_location(self) ;)
i rarely already have a __getattr__, and from what i've seen,
99% of classes written by other people don't either.
| As for 'what is wrong' with hiding state access behind methods (most
| of which don't actually DO anything but fetch state), a first
| example is: obj.price *= 1.07 # 7% increase versus
| obj.setPrice(obj.getPrice() * 1.07) # 7% increase
| Why force client code to go through the latter, more complicated
| form, when the simpler first form is available so cheap?
because, the latter is simpler. yes, it is more tedious to type. i
count this against augmented assignment :)
| Why force client-code to know and remember which attributes
| are actually 'in' the original object (and thus must be accessed
| through accessor methods, in your style) and which ones aren't (and
| thus must be accessed directly, unless one goes to the serious
| trouble of building up an accessor method and sticking it on
| on-the-fly -- blah!)...?
interesting point. i've never done this, seems like dubious practice
at first sight.
| These are pragmatical considerations that make direct, simpler
| notation preferable. On a _conceptual_ plane, the key issue is not
| confusing state and behavior. "Methods BEHAVE -- they DO stuff" and
| "properties JUST ARE -- I can 'read' them, and some of them I may
| also be allowed to 'write'" is a good pair of rules-of-thumbs to use
| as guidelines in deciding how to model something -- method, or
| property (attribute)? It's a very similar distinction to that
| between functions and variables.
so, you'd prefer most of the string methods that take no args in
python 2.0 were actually attributes? i don't know, somehow
doesn't seem pythonic to me.
More information about the Python-list