API suggestion: focus on RO ArrayBuffer(s) about proposal-limited-arraybuffer

[Jack-Works]

Actually, I think adding more different kinds of ArrayBuffer is really not a good idea.

For example, we have SAB today and we might have ResizableArrayBuffer and GrowableSharedArrayBuffer in the future.

And by this route we have to do a combination on those features:

• ArrayBuffer
• ReadonlyArrayBuffer
• SharedArrayBuffer
• ReadonlySharedArrayBuffer
• ResizableArrayBuffer
• ResizableSharedArrayBuffer
• GrowableSharedArrayBuffer

(why not add functionality to the current ArrayBuffer instead of new classes? cc @syg)

Yes, once I wrote that comment at the bottom of the post, I started to doubt it too. Viewing buffers as read-only might be better, as it would be more ergonomic if you have to create multiple views onto the same ro memory, because they wouldn't need multiple option bag arguments with readonly: true.

Besides that, it would end poorly, requiring separate classes for each and every intersection of ArrayBuffer subclass.

[Jack-Works]

And recently IMO ResizableArrayBuffer and GrowableSharedArrayBuffer have been rejected to stage 3 because they add new classes instead of options. I think that also applies to this one.