W3C home > Mailing lists > Public > public-script-coord@w3.org > April to June 2010

Re: Adoption of the Typed Array Specification

From: Erik Arvidsson <erik.arvidsson@gmail.com>
Date: Fri, 14 May 2010 11:04:36 -0700
Message-ID: <AANLkTimqqTdHssFhDx3BcGdsPFEHUtig-s9CN4tRFTS7@mail.gmail.com>
To: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>
Cc: Alex Russell <alex@dojotoolkit.org>, Chris Marrin <cmarrin@apple.com>, "arun@mozilla.com" <arun@mozilla.com>, "public-script-coord@w3.org" <public-script-coord@w3.org>, "es-discuss@mozilla.org" <es-discuss@mozilla.org>
On Fri, May 14, 2010 at 10:06, Allen Wirfs-Brock
<Allen.Wirfs-Brock@microsoft.com> wrote:
> What's your use case for a variable length ArrayBuffer?

I'm happy with fixed length array buffer but exceptions rubs me the
wrong way. Consistence with Array leads to less surprises which leads
to less bugs.

> These are the sorts of trade-offs that library writers should be making.  They can decided if it is more appropriate to build an abstraction that that grows by copying (probably best for infrequent growth and lots of iterative operations) or grows by segmentation (probably better for frequent growth with minimal iteration).  They can even include both in a library.
> The core language should be providing the primitive that enable this sort of library design while minimizing low level overhead.  From that perspective I think a fixed size ArrayBuffer is exactly what is needed.  However, it is also important that efficient copying is supported, possibly via a ArrayBuffer constructer alternative.

I agree that we need to provide the missing primitives, however;

If we only provide the primitives usability will suffer.

If we only provide primitives all js libraries will have to
reimplement a usable abstraction layer. This is leads to more code
which leads to higher latency and slower application.

Received on Friday, 14 May 2010 18:05:31 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:02 UTC