classes (was Re: Same again please for OOP)

[Erno Kuusela]

>>>>> "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.

[rest snipped]

  -- erno