Editorial: move from internal slots to associated concepts?

[MattiasBuelens]

trafficstars

In #1047, we migrated from ES-style "records" to web-style "structs". That got me thinking: should we migrate from "internal slots" to "associated concepts"? I'm not sure what the precise terminology is, but for example a Request class in fetch has an "associated request", "associated headers", etc. For streams, a ReadableStream would have an "associated disturbed flag", an "associated readable stream controller", etc.

This would allow cross-linking between concept definitions and their usages, and eliminate the problem from #825 entirely. We could also get rid of this note about our "foreign JavaScript specification conventions". 🙂

I suppose this will require a much bigger change than #1047, since we use internal slots much more than we use records.

[ricea]

I find the "internal slot" style easier to read. With the "associated concept" style you end with sentences like

If this’s do not flush is false, then set this’s decoder to a new decoder for this’s encoding, this’s stream to a new stream, and this’s BOM seen to false.

which you have to carefully parse.

I was under the impression that other WHATWG specs were going to move to the internal slot style, but I can't find any reference to it now.

[domenic]

I generally preferred the associated-concept style, but I'm not sure it's worth the substantial effort it would take to move. The better cross-linking would be nice indeed, although we could also accomplish that with internal slots.

We could also get rid of this note about our "foreign JavaScript specification conventions". 🙂

The use of completion values, with ?/!, would remain.