On Sat, Aug 24, 2002 at 11:33:38PM +0200, Alex Martelli wrote:
I am not talking about situations where the object does not meet your expectations and needs to be adapted - I'm talking about situations where it actually does and the only problem is how to describe that fact properly.
Adaptation IS one way to "describe that fact properly", given that checks are anyway constrained to happen at runtime. You just install an adapter from objects x of class X to protocol Y that receives x as an argument and whose body is just "return x" -- that's all.
I don't take it as given that "checks are anyway constrain to happen at runtime". I prefer a system that is future-proof enough to evolve into something that the compiler can use to do type inference. That is one of the reasons I don't want a typeclass / type category / interface / / type expression / whateveryouyouwannacallit to call any user-written Python code. (I don't want Python to become of those languages where user code can execute at compile time :-)
... what's the gain that would justify a further, special-purpose mechanism that's usable only (e.g.) when all of X's methods already have the right name and order of parameters, but then we'd have to switch to another if there is renaming or reordering to be done?
Being able to eventually perform many type checks earlier - at compile time or at module load time. Renaming and reordering really does have to be done at runtime in a dynamically typed language. Oren