[Python-3000] iostack and Oh Oh
Phillip J. Eby
pje at telecommunity.com
Mon Dec 4 02:43:44 CET 2006
At 08:12 PM 12/3/2006 -0500, Jim Jewett wrote:
>On 12/3/06, Bill Janssen <janssen at parc.com> wrote:
> > Phillip Eby writes:
> > > what you want a "mapping" to do may not be the same as what
> > > somebody else wants a "mapping" to do
> > That's when they'd use two different interfaces, of course.
>I think Phillip's point is that most people wouldn't, really. You're
>lucky if someone documents "mapping" rather than "dict". They are
>almost never more specific.
Exactly. I'm glad I decided to wait before answering this one, because you
nailed it all the way through in your reply. These are all 100% HCI
issues, not technical ones. In technical theory, there's absolutely
nothing wrong with inspecting interfaces. In practice, there is an awful
lot that goes wrong. Alas, there's nothing sadder than a beautiful theory
being ruined by an ugly fact, but declaring and inspecting rigid interfaces
(as opposed to say, typeclasses), is just such a ruined theory.
(Well, actually, interfaces aren't even that beautiful of a
theory. Typeclasses don't *declare* anything, they are just rules that
determine whether a type qualifies as a member of the typeclass. So they
follow the DRY (Don't Repeat Yourself) principle, because you don't have to
declare *twice* that you support something, as you do with
interfaces. With typeclasses, you can at least only lie about what the
*body* of your methods do, not whether you've implemented them. And you
get the benefit of default implementations, too.)
>I'm not sure these problems can't be worked around, but ... I'm not
>sure how, particularly without supplying default implementations right
>on the interface.
Yep - this is the typeclass solution, and IMO it's ideal for supporting
"wide" interfaces like "mapping" and "file".
Really, though, if I understand Guido's position correctly, the sticking
point re: generic functions and typeclasses is that he doesn't like having
either IFace.func(ob) or IFace(ob).func(), and is also opposed to having
'def something(arg:IFace):' automatically adapt 'arg' to IFace so you don't
have to use one of the other two syntaxes.
Of course, I've already said that ob.func() suffices in cases where you are
passing something that is *already* of appropriate type. That is, if your
caller invokes 'something(IFace(arg))' or just uses an object known to
conform to the desired interface, there's no need for the callee to adapt
or use a standalone function.
But I think that Guido finds this part somehow unsatisfying, because it
lacks the ability to perform a quick-and-dirty test on the interface
(instead of the *type*). Which is why I'm trying to highlight the fact
that interface *testing* (as opposed to adapting) leads to practical
problems that concrete type testing does *not* -- especially if the
concrete type testing is done via overloads instead of "if" blocks.
More information about the Python-3000