Re: Adoption of the Typed Array Specification

On May 13, 2010, at 11:09 PM, Oliver Hunt wrote:

> 
> On May 13, 2010, at 10:21 PM, Alex Russell wrote:
> 
>> On May 13, 2010, at 5:15 PM, Vladimir Vukicevic wrote:
>> 
>>> This is difficult to do, given the goals of typed arrays -- they wouldn't behave like normal Arrays in most meaningful ways.
>> 
>> Sounds like a bug to be fixed ;-)
>> 
>>> At the core, an ArrayBuffer is of fixed size, and it doesn't make sense to index an ArrayBuffer directly (because there's no indication of what format the data should be accessed in). Making the array view types instances of Array might work, but again given that they're fixed length, there's a significant difference there. 
>> 
>> 
>> That the length property of a particular array subclass leaves the constructor non-configurable and read-only isn't much of a trick in ES5. That said, why *doesn't* TypedArray spec a mutable variant? Surely it'd be useful.
> 
> The data is mutable, the length is not -- this is more in line with arrays in other languages, but more importantly the whole point of the typed array spec was to provide a compact typed storage mechanism.  Allowing the length to be changed runs counter to this as it effectively puts us back in the position of supporting sparse arrays.


To be clear, I'm supportive of a fixed-length array type for efficient handling of byte types. I'm *also* in favor of supporting mutable-length arrays for these types as well, perhaps as a separate subtype of Array or a type that shares some traits but not others. I get the need to optimize the case of "I'm representing a buffer somewhere in some C code and need to do it as fast as possible", but I just don't think that should be the exclusive use of relatively efficient byte arrays, even if it's the one that's motivating WebGL at the moment.

Regards

--
Alex Russell
slightlyoff@google.com
alex@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723

Received on Friday, 14 May 2010 06:23:31 UTC