- From: Anne van Kesteren <annevk@annevk.nl>
- Date: Mon, 29 Jul 2013 17:37:55 -0700
- To: Jonas Sicking <jonas@sicking.cc>
- 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 4:13 PM, Jonas Sicking <jonas@sicking.cc> wrote: > On Mon, Jul 29, 2013 at 3:20 PM, Anne van Kesteren <annevk@annevk.nl> wrote: >> 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? I'm not a big fan of having mutually exclusive accessors for data and passing it as an argument could work too, but given that you want to read multiple times that does not seem super convenient. -- http://annevankesteren.nl/
Received on Tuesday, 30 July 2013 00:38:21 UTC