> 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.
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