Re: ducktyping

[Eike Decker <eike@...>]

Zitat von Veli-Pekka Tätilä <vtatila@gmail.com>:

> Eike Decker wrote:
> > "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
> > language's dynamism."
> >
> > I think I'll refer to that page if someone asks me *again* how to
> > implement static typing 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 
> app.
> 

Hm. Suppose that you have two java libs that are both offering easy to use
functions for complex algorithms (i.e. matrices), but both libs are written by
different teams with different codebases, i.e. you have two different class
definitions of the clase "Matrix" - next to your own implementation. You would
have for example same functions with different names, i.e. "identity()" vs.
"loadIdentity()" and so on. How would you solve this problem in an elegant
approach in a static language? 

I don't think that the problems that you are naming are specifically problems of
duck typing (actually duck typing seems to me to be the best solution in that
case that I can think of right now). Or maybe I got you wrong? ;)

Eike