- From: Alex Russell <alex@dojotoolkit.org>
- Date: Fri, 14 May 2010 11:07:36 -0700
- To: Erik Arvidsson <erik.arvidsson@gmail.com>
- Cc: Allen Wirfs-Brock <Allen.Wirfs-Brock@microsoft.com>, 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 May 14, 2010, at 11:04 AM, Erik Arvidsson wrote: > 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. +1. What Erik said. -- Alex Russell slightlyoff@google.com alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723
Received on Friday, 14 May 2010 18:08:32 UTC