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 slightly...@google.com a...@dojotoolkit.org BE03 E88D EABB 2116 CC49 8259 CF78 E242 59C3 9723 _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
