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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4