Add base types of ArrayBuffer, SharedArrayBuffer

[cometkim]

TypedArray.prototype.buffer is polymorphic. ArrayBuffer or SharedArrayBuffer

Atomics is mostly used with Int32Array on SAB.

It's quite a corner case, but not a common use case, so I think it's not practical to make the module structure or type variants represent it strictly.

[cometkim]

This should be moved into Core. Onlt type t should be remained here

[DZakh]

I'd suggest marking the record as private so it's not possible to create by hand.

[DZakh]

Since not every record with the fields is the ArrayBuffer

[cometkim]

That's basically prevented by nominal typing

[DZakh]

I mean to prevent the code like this:

let myArrayBuffer: Js.ArrayBuffer.t = {
  byteLenght: 2,
  maxByteLength: 4,
  detached: false,
  resizable: false
}

[cometkim]

If we don't want that, we shouldn't use the binding pattern of exposing getters as record fields for every this-bounded object.

I thought it was already a widely used (even encouraged) pattern, more for practicality than strictness. for example: TheSpyder/rescript-webapi#78 (comment)

[DZakh]

I personally use private for my projects. It kind of solves the problem:

type t = private {
  byteLength: int,
  maxByteLength: int,
  detached: bool,
  resizable: bool,
}

But I see one downside compared to getter pattern:

You need to annotate the value when you access the field

let fn = (arrayBuffer: ArrayBuffer.t) => arrayBuffer.byteLenght
// vs
let fn = (arrayBuffer) => arrayBuffer->Js.ArrayBuffer.byteLength

It's fine for this case but when you have a type with a lot of complicated type arguments I prefer not to write annotations.

[cometkim]

Maybe we can just leave type t here, but what about the Core's direction? @zth

I'll tune in to that.

[cometkim]

Wait, so does it make sense to provide compatibility with Js' type in the first place?

[cometkim]

ok I'm going to close this and move it to Core entirely. If the direction is to remove JS in v12, I think there is no reason to change here, regardless of whether type t is extended or not. The only reason is compatibility with v11 but that can wait.