Use "." notation for all internal slots

[annevk]

Instead of "The [[X]] internal slot value of Object" it seems we could simply use Object.[[X]] as is already done for Records. Or is there a reason there is this distinction?

(FWIW, the WHATWG Streams Standard uses Object@[[X]] as convention and folks don't really understand why it's different, including the editor, who defers to this repository.)

[ljharb]

This seems both unconfusing and like it will reduce verbosity without reducing clarity.

[ljharb]

This seems both unconfusing and like it will reduce verbosity without reducing clarity.

[domenic]

Yeah, I agree with @ljharb.

At first I thought it was important to distinguish records from JS objects, but doing that by choosing what sigil should be used to access their state is dumb. (I.e., it doesn't help in cases where you're not accessing state, but just using the variable.)

Then I thought it was important to distinguish internal slot access from property access, but that is already done by the [[ notation.

So this seems unambiguous and a clear win.

[domenic]

Yeah, I agree with @ljharb.

At first I thought it was important to distinguish records from JS objects, but doing that by choosing what sigil should be used to access their state is dumb. (I.e., it doesn't help in cases where you're not accessing state, but just using the variable.)

Then I thought it was important to distinguish internal slot access from property access, but that is already done by the [[ notation.

So this seems unambiguous and a clear win.

[jmdyck]

The spec already has Object.[[X]] in a few places, but I believe all occurrences are for internal methods, not internal slots. E.g., IsExtensible() invokes _O_.[[IsExtensible]]().

[jmdyck]

The spec already has Object.[[X]] in a few places, but I believe all occurrences are for internal methods, not internal slots. E.g., IsExtensible() invokes _O_.[[IsExtensible]]().

[ljharb]

To me, an internal method is just a function-valued internal slot - exactly like an object method is just a function-valued object property.

[ljharb]

To me, an internal method is just a function-valued internal slot - exactly like an object method is just a function-valued object property.

[jmdyck]

To me, an internal method is just a function-valued internal slot

(Presumably you mean "function" in a general sense, not the ES-specific sense.)

I think the spec is mostly okay with that interpretation. But note that:

• [[RegExpMatcher]] is not referred to as an internal method even though it's an internal slot whose value is an algorithm.
• Invoking an object's internal method is not quite as simple as invoking the value of an algorithm-valued internal slot: the former also sets the 'target' of the invocation.

Bringing it back to the subject of this issue, I think using dot notation makes more sense for internal slots than it does for internal methods; since the spec is already using it for methods, might as well for slots too.

[jmdyck]

To me, an internal method is just a function-valued internal slot

(Presumably you mean "function" in a general sense, not the ES-specific sense.)

I think the spec is mostly okay with that interpretation. But note that:

• [[RegExpMatcher]] is not referred to as an internal method even though it's an internal slot whose value is an algorithm.
• Invoking an object's internal method is not quite as simple as invoking the value of an algorithm-valued internal slot: the former also sets the 'target' of the invocation.

Bringing it back to the subject of this issue, I think using dot notation makes more sense for internal slots than it does for internal methods; since the spec is already using it for methods, might as well for slots too.

[bterlson]

Using dot notation everywhere seems fine to me. Anyone want to tackle this regexp replacement? :-P

[bterlson]

Using dot notation everywhere seems fine to me. Anyone want to tackle this regexp replacement? :-P

[jmdyck]

I'll have a go.

[jmdyck]

I'll have a go.

[bterlson]

Alright, this seems done. We don't use it for internal methods, but that can be considered separately in #595.

[bterlson]

Alright, this seems done. We don't use it for internal methods, but that can be considered separately in #595.