[PEAK] Re: PyProtocols subsets

[Phillip J. Eby]

At 02:15 PM 7/14/04 -0500, Matthew Scott wrote:

>Phillip J. Eby wrote:
>>Hi Matt.  I just sent a comment to your blog about your post; 
>>unfortunately your workaround will cause you problems later, and there is 
>>a much better way.  I'd just wait until you get the comment and moderate 
>>it, but I'm concerned that other people using PyProtocols may read your 
>>approach and emulate it, leading to Bad Things Happening.
>>Basically, the problem is that your code really *does* have an ambiguity: 
>>if you call IBase(X()), which adapter should be used, Y or Z?  That's the 
>>ambiguity, and it can be resolved simply by declaring *one* of the 
>>adapters as suitable for use by IBase(X()).
>>Anyway, if you could get the comment passed through ASAP for folks to 
>>see, or make another post, I'd appreciate it as far as not leading others 
>>into error.  :)  Thanks.
>>(And also thanks for indirectly pointing this issue out, which should 
>>ultimately become part of the PyProtocols doc, or perhaps a FAQ of some sort.)
>Hi Phillip...
>
>Thanks for the response.  I've updated the post with an update message at 
>the top and touched the timestamp on it so it would show up again in some 
>aggregators.  I'll be updating it again to reflect the "right" way to do 
>it, as well as updating the Wiki page that I created on the PEAK wiki 
>regarding this.
>
>After reading your comment several times it finally sank in that declaring 
>an adapter for the "base" interface was indeed the correct solution.
>
>Also, for our purposes the interfaces that are represented by "IBase" in 
>my example code are sort of "abstract base interfaces".  That is, they 
>exist to provide documentation about the interface so that several other 
>interfaces can just subclass from them without duplicating the existing 
>code.  In other words, we want to -never- allow something to be adapted to 
>IBase.
>
>For now, what we've done with our real-world code (and what I'll do when I 
>update my entry with a "correct" example) is to stop using 
>protocolIsSubsetOf and go back to the old subclassing of base interfaces, 
>and at each point where an adapter is declared for adapting something to 
>some interface subclass, we are preceding it with an adapter to the base 
>interface class with a DOES_NOT_SUPPORT factory.
>
>That took care of the problem quite handily!
>
>But we have another question now:  Is there any way to declare an adapter 
>such that *nothing* can be adapted to some base interface class?  In other 
>words, instead of fromObjects, fromTypes, or fromProtocols, to indicate 
>"fromAnythingAtAll" in a sense...
>
>If not, that is fine.  If so, that will make our code even more concise.

Have you tried defining your "abstract interfaces" as normal Python 
classes?  (i.e., not protocols).  This will give you the documentation 
aspect you want, without making them actual adaptable interfaces, and 
without creating any ambiguity.


>Thanks again for your help!

No problem; in truth I ran into this same problem just a day or two ago 
while working on generic functions; I made interfaces to represent 
comparability and hashability, and ran into the ambiguity problem.  At the 
time I just punted and copied the methods into the more-derived interfaces, 
since they were basically just __eq__ and __hash__.  Your posting forced me 
to actually address the issue, and your follow-up question now also makes 
it obvious what I should've done instead, and may go ahead and do later.

Personally, I think I'll use adjective names rather than INames for such 
classes, so as not to make it look like you can use adapt() with 
them.  That is, I'd probably make Hashable and Comparable rather than 
IHashable and IComparable.


>FYI - Feel free to cross-post your response to the PEAK mailing list if 
>you think it's appropriate to move this discussion there.  I read it via 
>gmane so I will see the response.