Re: Questions about the Prohibition of String Subclasses in responses

[Michael Koziarski <michael@koziarski.com>]

> What's the overhead of metadef-ing #concat/#append each String response
> on an individual basis vs subclassing?  That could be an option...

That's not really an option, we're not going to work around rack by
dynamically extending every buffer used in every rails app :).

> Also (not knowing much about Rails or view internals), would it be
> possible to make the response an Array-like object and then make all
> concats/appends work on the Array-like object instead of the String-like
> object?
>
>  class SafeBuffer < Array
>
>    def <<(string)
>      super(escape(string))
>    end
>
>    ...
>
>  end

We could do this, however ERB uses .to_s EVERYWHERE and it's very
tricky to get anything but a string out the other end.  I'd rather not
go down that path if we can avoid it at all.

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.

Having said that, I've been surprised before

> But I just read the patch attached to LH ticket #78 and that relaxes
> the Hash type check, too.  I actually depend on that being a real
> Hash in at least C one extension :x

I'm not too worried on the Hash front, but it still seems wrong to
make the assumption that consumer classes can't handle subtypes

> I'll of course update that extension for the new spec if I need to :>
>
> --
> Eric Wong
>

[1] http://en.wikipedia.org/wiki/Liskov_substitution_principle


-- 
Cheers

Koz