static methods

[Christian Tanzer]

"Alex Martelli" <aleaxit at yahoo.com> wrote:

> "Rick Lee" <rwklee at home.com> wrote in message 
> news:3ABD7673.9D447A32 at home.com...
> > Thanks, and thanks to Alex.  This is very useful, also very telling that
> it
> > is pretty obscure.  For me, static, or class-wide methods are very useful.
> > With this, you only have to pass the class reference to the caller.
> > Otherwise, you have to pass both the class reference and the module
> > reference to the caller.
> 
> Actually, the module reference will suffice; it will contain suitably
> named callables to:
>     -- generate instances of the class (the class-object itself and/or
>         suitable factory functions),
>     -- do whatever else you need to be done class-wise.
> 
> You can package up those callables any way you want; there is
> really no special reason they should be attributes of the class
> object as opposed to that of any other object, and a module
> object is typically handiest.

This seems to be the standard answer on c.l.py. I'm not convinced.

There are two cases:

- Modules defining a single class.

  In this case, most people would use the same name for both module
  and class. If you need the module object for scoping purposes, you
  end up with code using lots of `Bletch.Bletch' which I find
  atrocious.

  Rick also talked about passing around a reference to the class. If
  you pass a reference to a module instead, you need a convention how
  to refer to the class defined by the module.
  `getattr (module_reference, module_reference.__name__)' isn't any
  better than `Bletch.Bletch'. Another possibility would be to use
  `Module.Class' but that doesn't seem like a good idea, either (it 
  definitely smells of Ada-83 to me).

- Modules defining multiple classes. In this case, passing a module
  reference instead of a class reference won't fly, anyway.

  You could dismiss modules with multiple classes out of hand, but
  IMNSHO this would be rash (and inconsistent with your approval of
  Lakos' ideas about large scale design).
  
> The desire to use the class-object specifically, rather than any
> other, typically seems to have more to do with familiarity with
> other languages where classes must play certain special roles
> (C++, Java, Smalltalk, Eiffel) than with any actual programming
> needs.

I used languages with strong emphasis on the module as primary
construct (like Modula-2 and Ada) and languages favoring the
class as the primary construct (like Eiffel and C++). I found the
latter much better suited to my programming needs. That doesn't mean
that I shun modules, though. Fortunately, Python doesn't force either
direction (with some tricks to get class functions).

-- 
Christian Tanzer                                         tanzer at swing.co.at
Glasauergasse 32                                       Tel: +43 1 876 62 36
A-1130 Vienna, Austria                                 Fax: +43 1 877 66 92