W3C home > Mailing lists > Public > public-script-coord@w3.org > January to March 2015

Re: Idiomatic representation of { buffer, bytesRead }

From: Jason Orendorff <jason.orendorff@gmail.com>
Date: Wed, 4 Mar 2015 05:06:57 -0600
Message-ID: <CAPh8+Zpi3yVLm3o_8ugD=2XjoH57ttJ7RoDuSXB+5wuYkdpTWA@mail.gmail.com>
To: Domenic Denicola <d@domenic.me>
Cc: "es-discuss@mozilla.org" <es-discuss@mozilla.org>, "public-script-coord@w3.org" <public-script-coord@w3.org>
On Mon, Mar 2, 2015 at 3:45 PM, Domenic Denicola <d@domenic.me> wrote:
> While working on lower-level byte streams we're encountering a number of situations that need to return something along the lines of `{ buffer, bytesRead }`. (In this setting "buffer" = ArrayBuffer.) In the most general form the signature ends up being something like
>
>     { sourceBuffer, offset, bytesDesired } -> { newBuffer, bytesRead }

I very much like 2 and 3 because they provide the result type that the
user wants anyway. Slightly prefer DataView.

But you can support both, like this:

    pull(DataView) -> Promise<DataView>
    pull(TypedArrayView) -> Promise<TypedArrayView of the same type>

A view argument conveniently provides just the three pieces of
information you need, plus a type.

The lower-level primitive could take an optional fourth argument:

    pull(sourceBuffer, offset, bytesDesired,
resultConstructor=DataView) -> Promise<resultConstructor>

This could even be generic in resultConstructor, though it's a little
awkward because you have to divide by
resultConstructor.BYTES_PER_ELEMENT before invoking the constructor.

-j
Received on Wednesday, 4 March 2015 11:07:28 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 4 March 2015 11:07:28 UTC