Re: Overlap between StreamReader and FileReader

On Mon, Jul 29, 2013 at 5:37 PM, Anne van Kesteren <annevk@annevk.nl> wrote:
> 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.

I'm not sure that there's anything "mutually exclusive" here? Other
than that data that .read has consumed can't be consumed by .readText.
But that's an effect of that .read/.readText throws away the data
after it has been consumed, rather than an effect of that we have two
different ways of consuming data. I.e. .readText is as exclusive to
.read, as .read is to itself.

/ Jonas

Received on Tuesday, 30 July 2013 00:57:01 UTC