[Python-Dev] PEP 246, redux

[Phillip J. Eby]

At 01:19 PM 1/10/05 -0500, Clark C. Evans wrote:
>Alex,
>
>   This is wonderful work, thank you for keeping the ball in the air;
>   I'm honored to keep my name as a co-author -- kinda like a free lunch.
>
>Phillip,
>
>   Once again, thank you!  Without PyProtocols and your advocacy,
>   this proposal might have been buried in the historical bit-bucket.
>
>On Mon, Jan 10, 2005 at 12:43:44PM -0500, Phillip J. Eby wrote:
>| -1 if this introduces a performance penalty to a wide range of
>| adaptations (i.e. those using abstract base classes), just to support
>| people who want to create deliberate Liskov violations.  I personally
>| don't think that we should pander to Liskov violators, especially since
>| Guido seems to be saying that there will be some kind of interface
>| objects available in future Pythons.
>
>I particularly like Alex's Liskov violation error; although it is
>not hugely common, it does happen, and there should be a way for a
>class to indicate that it's only being used for implementation.
>
>Perhaps... if the class doesn't have a __conform__ method, then its
>adaptation is automatic (that is, only the class can raise this
>case).  The rationale for only enabling one of the two paths is that
>the base class would have been in-place before the derived class was
>created; therefore, it is highly unlikely that __adapt__ would ever
>be of help.  Therefore, there might be a performance penalty, but it'd
>be really small, simply checking to see if the slot is filled in.

The performance penalty I was talking about was for using an abstract base 
class, in a subclass with a __conform__ method for conformance to other 
protocols.  In this case, __conform__ will be uselessly called every time 
the object is adapted to the abstract base class.

IMO it's more desirable to support abstract base classes than to allow 
classes to "opt out" of inheritance when testing conformance to a base 
class.  If you don't have an "is-a" relationship to your base class, you 
should be using delegation, not inheritance.  (E.g. 'set' has-a 'dict', not 
'set' is-a 'dict', so 'adapt(set,dict)' should fail, at least on the basis 
of isinstance checking.)

The other problem with a Liskov opt-out is that you have to explicitly do a 
fair amount of work to create a LiskovViolation-raising subclass; that work 
would be better spent migrating to use delegation instead of inheritance, 
which would also be cleaner and more comprehensible code than writing a 
__conform__ hack to announce your bad style in having chosen to use 
inheritance where delegation is more appropriate.  ;)

This latter problem is actually much worse than the performance issue, 
which was just my initial impression.  Now that I've thought about it some 
more, I think I'm against supporting Liskov violations even if it were 
somehow *faster*.  :)