teaching OO [ + multimethods & @decorators ]
Ville Vainio
ville at spammers.com
Wed Nov 24 14:27:00 EST 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