teaching OO [ + multimethods & @decorators ]

Ville Vainio ville at spammers.com
Wed Nov 24 20:27:00 CET 2004


>>>>> "Gabriel" == Gabriel Zachmann <zach at cs.uni-bonn.de> writes:

    >> I don't think virtual classes (as in inheriting from base classes
    >> "virtually" to avoid a certain multiple inheritance problems) is all
    >> that important in this single inheritance favouring world.

    Gabriel> ah, sorry, i meant "classes with virtual methods" (i.e.,
    Gabriel> classes that have RTTI).

Ah, ok. Python has the clear upper hand here because everything is
"virtual", type(obj) is always the "most derived" version.

BTW, a slight terminology correction - having a "virtual table"
doesn't necessitate existence of RTTI, in fact some systems (Symbian
OS at least) omit RTTI on purpose but still have virtual
functions. Having RTTI means dynamic_cast<Foo>(obj) can return NULL if
obj can not be cast to Foo, while e.g. in Symbian OS C++ environment
dynamic_cast is just the same as static_cast, with all the Access
Violations that go with it :-).

    >> The concept of overloading is easy, you can go one step further by
    >> introducing generic functions / multimethods through one of the
    >> modules floating around the net.

    Gabriel> You mean in Python? (or C++)
    Gabriel> Could you give me a pointer to one of those modules?

http://www-106.ibm.com/developerworks/linux/library/l-pydisp.html

http://www.cis.upenn.edu/~edloper/pydecorators.html

(the last one has the wrong guess for @decorator syntax, and so has
the examples wrong).

Google for "python generic function decorator" or something along
those lines for more. I bet we'll see one @decorator implementation
become pretty "standard" once Python 2.4 goes final.

-- 
Ville Vainio   http://tinyurl.com/2prnb



More information about the Python-list mailing list