[Python-3000] iostack and Oh Oh

[Phillip J. Eby]

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.