[Catalyst] Re: Avoiding UTF8 in Catalyst

[Jonathan Rockway]

* On Tue, Dec 08 2009, Aristotle Pagaltzis wrote:

<snip pedantry>

> This will work only if the string is using one of the two kinds
> of internal representation but not in the other.

Exactly my point.

> The case the OP had was that he wanted to send Latin-1 and his
> strings contained sequences of Latin-1 characters, which happen
> to be interchangeable with their octet representation. His
> strings were getting upgraded in the course of the code, which is
> hardly uncommon with Latin-1 strings and in fact is necessary in
> some cases.
>
> It should not have mattered that they were upgraded. Their
> content was semantically correct. But it did matter, because
> Catalyst::Engine used bytes::length, so forced the user to care
> about the internal representation.

It wouldn't have mattered if he had Encode::encode'd to latin-1, right?
He didn't do that, so the app broke.  Using length instead of
bytes::length would have fixed his app, but would have broken apps that
are using UTF-8 encodings and also forgot to Encode::encode.

The fact that either program works is an undocumented side-effect.  But
changing that side-effect would break currently-working apps, and we
don't want to do that.  Like I said, bytes::length is not there to be a
good example of Modern Perl.  It is there so that people don't have to
fix their broken apps today.  Catalyst got this wrong from the
beginning, so we are stuck until we have a good way to make everything
work for everyone.  (I am experimenting with a new response layer on top
of Plack that should prove useful for this sort of thing.)

Wow, I can't believe I am defending backcompat.  Must be that caffeine
powder...

Regards,
Jonathan Rockway

--
print just => another => perl => hacker => if $,=$"