[Python-Dev] re: *very* revised proposal for interfaces

Esteban U.C.. Castro esteban@ccpgames.com
Thu, 3 Oct 2002 10:09:04 -0000


> For my purposes, I'm not sure the error checking is really a Good
Thing
> after some of the things Esteban Castro pointed out.  If you fail to
> implement the nesessary methods, that's your own problem.  This
approach
> is a lot less work for me, and handles strange cases of late binding
> more gracefully.  Of course a warning would be helpful in the 95% of
> cases where the assumptions made for error checking are correct.

I think you misinterpret me here. I am not against checking an
interface.=20
Indeed, checking would be the only way to detect implicit interface=20
compliance (one of my main points).

>>> from interfaces import ListInterface
>>> a =3D [1,2,3]
>>> implements(a, ListInterface)
1
>>> implements(a[0], ListInterface)
0
>>> import my
>>> b =3D my.SuperDuperFakeList()
>>> implements(b, ListInterface)
1

It should be possible to define ListInterface once and check it against
any arbitrary object, without having to fiddle with, or provide adapters

for the type/class of each object that does (de facto) implement it.=20

For example, I don't want to have to do __bindings__ on the list type,=20
UserList, any extension types designed to be used as lists, wrappers or=20
proxies on lists that are not instances of UserList, etc.=20



Declaring that a class implements an interface (this is, it promises
that=20
all its instances will satisfy it) still makes sense:


* For documentation: declaring compliance with an interface gives a very

  useful hint on the purpose and usage of the class.


* For safety: you may be afraid that satisfying some method signatures
alone=20
  doesn't guarantee that an object is safe to use in contexts where your

  interface is required.=20

  For example, you have this my.Shape interface with this draw() method.
There=20
  are too many classes around that provide a draw() method and which
won't=20
  work for the purposes of my.Shape (and that's why a simple check for
draw()
  is not enough either). Implicit interface satisfaction is not a
concern here,=20
  because it doesn't make sense that anyone has implemented useful
my.Shapes=20
  before knowing about your module. So it makes full sense for you to
require=20
  that any objects that want to implement my.Shape explicitly declare
so. This=20
  does not necessarily replace checking for draw(). The author of each
specific=20
  interface must decide her policy on this.


* For performance: you may want to cache the results of class checks.
You may
  even do without checking at all, but I don't think this is a good
idea.


I have my own ideas on how the syntax should be but I'd rather bounce
them and=20
let them mature off this list. If anyone is willing to put up a mailing
list or=20
just discuss these things privately, please let me know.


Esteban.