Re: Should send() be able to take an ArrayBufferView?

On Wed, Apr 11, 2012 at 7:19 PM, Kenneth Russell <kbr@google.com> wrote:

> On Wed, Apr 11, 2012 at 5:05 PM, Glenn Maynard <glenn@zewt.org> wrote:
> > (I don't think there's any particular reason for ArrayBuffer to be
> opaque.
> > It would have been nice if ArrayBuffer acted like an Int8Array, so you
> can
> > access the contents as an array of bytes without an extra step.)
>
> That's the way Java's New I/O API worked and it caused asymmetries in
> the API. I believe it was Chris Marrin who originally proposed
> factoring out the storage into ArrayBuffer and that has worked out
> very nicely. For example, ArrayBuffer is the only Transferable
> interface in the spec, and all of the view types are equal peers in
> the spec.
>

Java isn't known for well-designed APIs.  Just because a Java API does
something badly doesn't mean it can't be done well; there's no reason that
supporting 8-bit access to an ArrayBuffer would cause asymmetries.

For example, a reasonable API might be:

class ArrayBufferView; // buffer, byteOffset, byteLength
class ArrayBuffer: ArrayBufferView; // buffer points to itself; byteOffset
is always 0; provides Int8Array access
class Int16Array: ArrayBufferView;

which allows ArrayBuffer to be used directly, eliminates most of the
unnecessary differences between ArrayBuffer and array views, and allows
APIs like XHR2 to simply accept ArrayBufferView and work on everything,
instead of having separate ArrayBuffer and ArrayBufferView overloads.  It's
a much simpler API.

(This could almost be done today with a good chance of not breaking
existing code.  Unfortunately, the TypedArray(TypedArray) vs.
TypedArray(ArrayBuffer) constructors probably make it not possible, since
the former makes a copy and the latter doesn't.  That's an unfortunate
inconsistency in and of itself...)

-- 
Glenn Maynard