Re: Questions about the Prohibition of String Subclasses in responses

[Eric Wong <normalperson@yhbt.net>]

Michael Koziarski <michael@koziarski.com> wrote:
> I guess fundamentally I'm still not seeing a reason for the current
> restriction to no-child-classes beyond 'might break C-extensions'.
> What kind of code is in those c extensions which might break? We could
> verify our subclasses with that same kind of code and see what
> happens.  The whole purpose of inheritance is to ensure subtypes can
> be used interchangably, we've put some effort into making sure we're
> 'liskov-approved'[1] and I'd be surprised if anything breaks.

Actually, I think the vast majority of subclasses are safe.

Very contrived, but only(?) subclasses implemented in C that redefine
their internal representation to something incompatible with their
(expected) superclass would get broken (when accessed by other C
extensions).

Fortunately I don't know of any extensions that crazy as there's no
point in subclassing at that point.  And if there are, maybe people
using them deserve to get their apps broken :>

> Having said that, I've been surprised before

Part of me wants to apply this change and stick it into a release just
to see what (if anything it) breaks.  Fortunately for the rest of you
I'm not part of the Rack core team :)

-- 
Eric Wong