gah! I hate the new string syntax

[Alex Martelli]

"Quinn Dunkan" <quinn at retch.ugcs.caltech.edu> wrote in message
news:slrn9avqlm.8ee.quinn at retch.ugcs.caltech.edu...
> On Mon, 12 Mar 2001 17:56:33 +0100, Alex Martelli <aleaxit at yahoo.com>
wrote:
    [snip]
> >a typeswitch -- a very unadvisable construct.  Something like Haskell's
> >typeclasses, on the other hand, would provide the best of both worlds
> >(multimethods would be an even more powerful alternative) -- let the
> >compiler/interpreter/runtime do the dispatching, and just code in
    [snip]
> Note that in ruby, any time you write
>
> class Foo
>     ...
> end
>
> you are adding to, not overriding, 'Foo'.  Thus,

In Python, you can similarly add whatever Foo attribute you desire at
any time (even add a whole mixin class, &c); the tradeoffs are similar
(for classes -- Python has the added issue of the type/class split).

> Naturally, in a statically-typed functional language like haskell, these
> issues don't come up.  But in an imperative language, it's like frobbing
> __builtins__ ---probably not a very good idea.

Right.  But typeclasses need not be 'invasive' -- I think they could
be implemented dynamically, e.g. in some future Python version.

Now that might be a really powerful use for 'typechecking'.  At
any point I can assert that object X belongs to typeclass Y and
get back a Y-reference -- same as X if isinstance(X,Y) in the
normal Pythonic sense, or else some suitable wrapper when
I've registered with typeclass Y the way to make some existing
type X conform to it.  Now, I can call whatever methods of Y
I desire on that reference.  Hmmm, that might not be _too_
hard to implement in Python, syntactic sugar apart, now that
I think of it.

> In haskell, I could have simply defined a 'Taggable' class and instances
> implementing 'tagof' in the Display module... no problem.  But
"traditional"
> OO seems to make the solution much less clear...

Interesting train of thought...


Alex