> -----Original Message----- > From: es-discuss-boun...@mozilla.org [mailto:es-discuss- > boun...@mozilla.org] On Behalf Of Alex Russell ... > > 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. >
What's your use case for a variable length ArrayBuffer? ArrayBuffer seems like a low level building block that is going to be uses as a basis for constructing other higher level abstractions. As such it should be as simple and efficient as possible. The more complex we make the primitive entity the more likely it is to have implementation inefficiencies induced by features that are unlikely to be needed for some of the higher level uses. Consider growable buffers. At an implementation level, growth is either going to require copying or use of segmented buffers. The copying alterative probably requires an extra level of indirection on each access. The multi-segment approach complicates (and hence probably slows down) all accesses and certainly iterative operations. In either case, there is a penalty that accrues for the most common use case of a non-growable buffer. 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. Allen _______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
