Re: Adoption of the Typed Array Specification

On May 14, 2010, at 7:27 AM, Chris Marrin 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.
> 
> One of the important aspects of ArrayBuffer is its fixed length. As I mentioned before, perhaps the issue here is the poor naming (using "Array" in the names of objects that don't behave in the same way as the ES Array object). The names can be changed but I think we need the concept of a fixed length buffer with fixed views into it.


Yes, yes, I get that everyone with a C buffer they want to expose to JS wants a variant of ArrayBuffer that's fixed. But what I'm arguing for is that we can keep everything rational (instead of adding a "host object", committee speak for "alien weirdo") by making one type of ArrayBuffer (FixedArrayBuffer?) have a fixed length but *also* support a mutable length ArrayBuffer. Not exclusive, but in parallel and in a way that allows all of this to have a rational class hierarchy.

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 16:35:52 UTC