- From: Jonas Sicking <jonas@sicking.cc>
- Date: Mon, 29 Jul 2013 16:13:30 -0700
- To: Anne van Kesteren <annevk@annevk.nl>
- Cc: Takeshi Yoshino <tyoshino@google.com>, Feras Moussa <feras.moussa@hotmail.com>, Travis Leithead <travis.leithead@microsoft.com>, Alex Russell <slightlyoff@google.com>, "Web Applications Working Group WG (public-webapps@w3.org)" <public-webapps@w3.org>
On Mon, Jul 29, 2013 at 3:20 PM, Anne van Kesteren <annevk@annevk.nl> wrote: > On Mon, Jul 29, 2013 at 1:16 PM, Jonas Sicking <jonas@sicking.cc> wrote: >> Couldn't we simply let the Stream class have a content type, which >> could contain an encoding. Then when stream.readText is called, if >> there's an explicit encoding, it would use that encoding when >> converting to text. > > How about we use what XMLHttpRequest and WebSocket have? > > Stream.prototype.readType takes an enumerated string value which is > "arraybuffer" (default) or "text". > > Stream.prototype.read returns a promise fulfilled with the type of > value requested. I'm not sure that comparisons with XHR really works since XHR.responseType affects the parsing behavior, not the decoding behavior. And with WebSocket what you control isn't the result of an operation, but rather the contents of future events. So additional arguments or separate signatures isn't really an option there. I still think that your proposal works. But I don't quite see the advantage of it. Seems like it simply breaks out one of the arguments from the read function and passes it through state. Is the problem you are trying to solve having shorter function names? / Jonas
Received on Monday, 29 July 2013 23:14:27 UTC