Possible spec cleanup: Reuse internal slot names

[littledan]

The TypedArray/ArrayBuffer/DataView spec already has some overlap for slot names. Maybe you can reduce duplication by just calling the slots that are parallel to ArrayBuffer slots by the same name, and then having another internal slot that indicates whether it's shared or not (maybe with a string as the value?). This would reduce the volume of spec text, which has the implementation-friendly benefit that we don't have to read each line carefully to see if there's a distinction between the two cases when they're the same. You can decide whether or not certain methods (like slice) should be inter-compatible; if you don't want them to, then simply put an extra type check for that internal brand slot at the top of the method.

[lars-t-hansen]

I'm probably pretty resistant to this change (for one thing I don't think it's a simplification) but let's chat at the meeting and get some meat on the bone.

[leobalter]

I've just read the specs and had this same idea. Have you talked about it in the meeting with any definition?

Following the same reuse idea, the API for SharedArrayBuffer constructor and properties could be defined as in %TypedArray%.prototype methods: "ShareArrayBuffer is a distinct function that implements the same algorithm as ArrayBuffer as defined in 24.1.2.1 except that AllocateSharedArrayBuffer is called instead of AllocateArrayBuffer._"

That is helpful to keep both methods with the closest seamless implementation, especially when there's a chance to change ArrayBuffer in tc39/ecma262#410. This is also help on properties as byteLength, slice, etc.

[lars-t-hansen]

This did not actually get discussed at the March meeting :-/

I am still resistant to this change. As I wrote earlier I don't think it's a simplification, but perhaps I don't understand the implications - can somebody offer a PR to make the case? In addition I am concerned (paranoid might capture it better) that operations and semantics that are included in the spec for the sake of ArrayBuffer (unshared memory) become defined on shared memory, when they should not be.

[littledan]

I think places where SharedArrayBuffers are prohibited should be restricted by explicit type checks for ArrayBuffers. If you try to read one of the ArrayBuffer's internal slots on a SharedArrayBuffer, this would be a spec bug anyway. But I am sympathetic to this argument--better to "segfault" like that and have some spec text duplication than to accidentally provide extra generality.

[lars-t-hansen]

OK. Closing this for now, but do reopen if anyone feels we should talk more about it.

I also note that this is essentially an editorial question and we can revisit at any time.

[littledan]

Looking at the current spec as it's more written out now, I still think that we should use shared slot names. There doesn't seem to be a semantic difference between the corresponding slot names; it is just a way to enforce type checks. But there are explicit type checks all over the place already.

[lars-t-hansen]

Not Dead Yet.

[lars-t-hansen]

@littledan, I've experimented some with this and it's probably fine. Current work is on the branch called "unified", you can diff tc39/spec.html against master (I find --word-diff works well for me) or load tc39/shmem.html into a browser to look at the formatted output.

Mostly this just moves complexity around but some algorithm changes do disappear from the proposal. (A couple new changes come in in the form of type guards, but I think they are smaller.)

@leobalter, I have not yet pursued your idea, the edits so far only get rid of the new internal properties SharedArrayBufferData and SharedArrayBufferByteLength.

[bterlson]

+1 to unified slot names, would make spec easier to read IMO.

[lars-t-hansen]

@leobalter, I'll open another bug to track your idea, we can follow up on that separately.