- From: Erik Arvidsson <erik.arvidsson@gmail.com>
- Date: Fri, 14 May 2010 11:04:36 -0700
- 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. -- erik
Received on Friday, 14 May 2010 18:05:31 UTC