- From: Glenn Maynard <glenn@zewt.org>
- Date: Sat, 24 Mar 2012 08:52:15 -0500
On Thu, Mar 22, 2012 at 8:58 AM, Anne van Kesteren <annevk at opera.com> wrote:
> Another way would be to have a second optional argument that indicates
> whether more bytes are coming (defaults to false), but I'm not sure of the
> chances that would be used correctly. The reasons you outline are probably
> why many browser implementations deal with EOF poorly too.
It might not improve it, but I don't think it'd be worse. If you didn't
use it correctly for an encoding where it matters, the breakage would be
obvious.
Also, the previous "automatically-streaming" API has another possible
misuse: constructing a single encoder, then calling it repeatedly for
unrelated strings, without calling eof() between them (trailing bytes would
become U+FFFD in the next string). That'd be a less likely mistake with
this, too.
Here's a suggestion, working from that:
encoder = Encoder("euc-kr");
view = encoder.encode(str1, {continues: true});
view = encoder.encode(str2, {continues: true});
view = encoder.encode(str3, {continues: false});
An alternative way to end the stream:
encoder = Encoder("euc-kr");
view = encoder.encode(str1, {continues: true});
view = encoder.encode(str2, {continues: true});
view = encoder.encode(str3, {continues: true});
view = encoder.encode("", {continues: false});
// or view = encoder.encode(""); // equivalent; continues defaults to false
// or view = encoder.encode(); // maybe equivalent, if the first parameter
is optional
The simplest usage is concise enough that we don't really need a separate
str.encode() method:
view = Encoder("euc-kr").encode(str);
If it has an eof() method, it'd just be a literal wrapper for
encoder.encode(), but it can probably be omitted.
--
Glenn Maynard
Received on Saturday, 24 March 2012 06:52:15 UTC