[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: ducktyping
- From: Veli-Pekka Tätilä <vtatila@...>
- Date: Wed, 24 Sep 2008 20:58:39 +0300
Eike Decker wrote:
I was familiar with the term but due to dabbling in Ruby, which I picked
after Perl but before Lua. If anyone has Programming in Ruby 2nd ed, it has
a whole instructive chapter on duck typing equally applicable to Lua. Here's
also, though the language is Ruby, a nice take on various approaches to
typing with a dynamic language:
"Duck typing is aided by habitually not testing for the type of arguments
in method and function bodies, relying on documentation, clear code, and
testing to ensure correct use. Users of statically typed languages new to
dynamically typed languages may want to add such static, (before
run-time), type checks which defeats duck typing, constraining the
I think I'll refer to that page if someone asks me *again* how to
implement static typing in lua.
I used to think for a long long time that somehow inheritance and
polymorphism are inherently related. Now I think, in Lua, inheritance from
anything is just a form of operator overloading (typically indexing) for
tables that happen to be objects or classes. And ducktyping is polymorphism
by name, never mind the classes involved. As to inheritance, nothing would
stop you from actually copying class data to individual objects, or using
closures to build objects. Inside-out-objects and mix-in classes are cool,
too, both being easy to implement in Lua.
I can think of two problems with duck typing, which I run into sometimes:
1. Naming. Even if objects would do the same thing, if their authors use a
different style of naming methods, they will not be directly compatible
without a bit of wrapping or proxying. Examples IsEmpty, empty, is_empty,
has_no_elems etc... In a way, one way round it is operator overloading when
it makes sense. Relational and arithmetic ops generally have a well defined
meaning as does size, indexing and iteration, so such algorithms are likely
to do well with duck typing via operator overloading. The empty example
could be the test # o == 0.
2. Sometimes the exact interface is not formally specified even in the docs.
Meaning that one has to read the code to be able to figure exactly which
methods need implementing and which not. Would be nice to be told, OK, these
methods got called, so implement at least them.
One solution is a test run with wrapping. Wrap the original class you want
to be compatible with. Do some logging before each method when using the
original class, by overriding __index, and then delegate to the original.
problem solved, now you see exactly which methods are actually needed in an
With kind regards Veli-Pekka Tätilä
Accessibility, Apps and Coding plus Synths and Music: