[Python-Dev] PEP 246, redux (original) (raw)
Phillip J. Eby pje at telecommunity.com
Tue Jan 11 21:30:19 CET 2005
- Previous message: [Python-Dev] PEP 246, redux
- Next message: [Python-Dev] PEP 246, redux
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
At 09:10 PM 1/11/05 +0100, Alex Martelli wrote:
On 2005 Jan 11, at 20:48, Phillip J. Eby wrote: ...
I'd rather not assume that class inheritance implies substitutability,
Hm, you should take that up with Alex then, since that is what his current PEP 246 draft does. :) Actually, the earlier drafts did that too, so I'm not sure why you want to change this now. What I've actually suggested here actually allows for inheritance=substitutability as the default, but also makes it trivially changeable for any given inheritance hierarchy by overriding conform at the base of that hierarchy, and without introducing a special exception class to do it. The base of the hierarchy has no idea of which subclasses follow or break Liskov subtitutability. It's just silly to site the check there. Moreover, having to change the base class is more invasive than being able to do it in the derived class: typically the author of the derived class is taking the base class from some library and does not want to change that library -- changing the derived class is not ideal, but still way better.
Stop; you're responding to something I didn't propose! (Maybe you're reading these posts in reverse order, and haven't seen the actual proposal yet?)
Clark said he didn't want to assume substitutability; I was pointing out that he could choose to not assume that, if he wished, by implementing an appropriate conform at the base of his hierarchy. This is entirely unrelated to deliberate Liskov violation, and is in any case not possible with your original proposal. I don't agree with Clark's use case, but my proposal supports it as a possibility, and yours does not.
To implement a Liskov violation with my proposal, you do exactly the same as with your proposal, except that you can simply return None instead of raising an exception, and the logic for adapt() is more straightforward.
- Previous message: [Python-Dev] PEP 246, redux
- Next message: [Python-Dev] PEP 246, redux
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]