Editorial: use dot notation for accessing internal slots

[jmdyck]

Specifically, change:

   the [[Foo]] internal slot of _O_  (132 occurrences)

and

   _O_'s [[Foo]] internal slot (265 occurrences)

to

   _O_.[[Foo]]

(Resolves issue #574)

[jmdyck]

Some things I didn't change...

There are 18 occurrences of

    the [[DateValue]] internal slot of this Date object

which I could conceivably have changed to

    (this Date object).[[DateValue]]

but didn't.

Similarly 1 occurrence of

    the active function object's [[Realm]] internal slot

Also, there are lots of occurrences of

    _O_ has a [[Foo]] internal slot

which could be changed to something like

    _O_.[[Foo]] exists

but I left those unchanged. (Likewise the negative version.)

Finally, we could use dot notation for internal methods more. I.e., there are occurrences of

    the [[Foo]] internal method of _O_

and

    _O_'s [[Foo]] internal method

that you might want changed to

    _O_.[[Foo]]

Let me know if you want a follow-up commit for any of those changes.

[bterlson]

Will take a look in a few minutes, but did you mean to include 216a965? I like the change anyway...

(this Date object).[[DateValue]]

Not a fan of this, current convention is better :)

O.[[Foo]] exists

I feel like this is a bit confusing - does it mean [[Foo]] has a value that is not undefined, or that the slot is there? I think the current convention is fine for now.

Finally, we could use dot notation for internal methods more.

I think these are good! Can you think of downsides? It removes the explicit verbage telling you the slot is a method, but from what I can see that is very obviously implied by context in all of the usages...

[bterlson]

Do we need "the value of" everywhere? Seems unnecessary to me.

Other than that (and the merge conflict I created), this change seems great!

[domenic]

+1 for removing "the value of"

[jmdyck]

did you mean to include 216a965?

Yup, because it allowed me to include those steps in the systematic changes of the main commit.

O.[[Foo]] exists

I feel like this is a bit confusing - does it mean [[Foo]] has a value that is not undefined, or that the slot is there?

It might be that a different verb would be less confusing. (I thought of suggesting O.[[Foo]] is present, but we already use the present/absent dichotomy in a bunch of other contexts.)

I think the current convention is fine for now.

Okay.

Finally, we could use dot notation for internal methods more.

I think these are good! Can you think of downsides? It removes the explicit verbage telling you the slot is a method, but from what I can see that is very obviously implied by context in all of the usages...

That was the only downside I could think of. I'll add a commit for those changes.

Do we need "the value of" everywhere? Seems unnecessary to me.

That occurred to me too, but I decided to leave it alone. I agree that it seems superfluous in text such as

If the value of _new_.[[ArrayBufferByteLength]] < _newLen_, ...

and

Set the value of _O_.[[ListIteratorNextIndex]] to _index_+1.

But consider

Let _V_ be the value of _O_.[[Foo]].

vs

Let _V_ be _O_.[[Foo]].

I think some people might read the latter as meaning that _V_ is now an alias for that slot, rather than a reference to the value currently there. Since the spec doesn't explicitly say what it does mean, I think "the value of" helps a little.

[domenic]

I disagree that "the value of" helps in those cases. I think most spec readers have enough experience with programming languages and spec-prose to understand that variable assignment is not generally pointer assignment.

[claudepache]

I don’t think it is a good change, because at first reading it may be interpreted as "If the value of p.[[GetPrototypeOf]]"...

[bterlson]

Isn't that first reading correct?

[claudepache]

@bterlson Yes if we consider that we have an internal slot whose value is an internal method. But I like to keep the distinction between internal slots and internal methods.

[claudepache]

For clarity, I think it is a good idea to use the notation O.[[Foo]] only when it specifically means: "the value of [[Foo]]’s internal slot of O".

[bterlson]

Regarding "the value of", I think we can make it clear by tightening up the description in 6.2.1 to say:

For example, if R is the record shown in the previous paragraph then R.[[Field2]] is shorthand for “the value of the field of R named [[Field2]]”.`

[jmdyck]

(except that Objects aren't Records, they just use the same notation for internal slots/methods)

[bterlson]

Yes, that should be clarified as well :)

[jmdyck]

@claudepache:

For clarity, I think it is a good idea to use the notation O.[[Foo]] only when it specifically means: "the value of [[Foo]]’s internal slot of O".

What do you intend to be excluded by emphasizing the words "the value of"? (Perhaps you mean that we shouldn't change _O_ has a [[Foo]] internal slot to _O_.[[Foo]] exists, because that isn't a reference to the value of the slot, merely to the existence of the slot. But @bterlson has already discouraged such a change, and this PR doesn't make it.)

And by saying "slot", do you mean to exclude internal methods?

[claudepache]

@claudepache:

For clarity, I think it is a good idea to use the notation O.[[Foo]] only when it specifically means: "the value of [[Foo]]’s internal slot of O".

What do you intend to be excluded by emphasizing the words "the value of"?

For example, "O.[[Foo]] exists" when it means "O has a [[Foo]] internal slot".

And by saying "slot", do you mean to exclude internal methods?

Probably, yes. For internal methods, use only the notation "O.[Foo]", and use it only when it means: "the value returned by calling the [[Foo]] internal method of O with argument bar.

[bterlson]

I am personally fine with the conceptual model where internal methods are internal slots with function-like values, but in the interest of moving this along without creating massive rebasing headaches, I think we can take everything but 000be90 and get a huge win. We can discuss using the dot-convention for methods in a separate issue. Thoughts @jmdyck?

[jmdyck]

Fine with me.

(Though I'm not sure how it works git-wise: do I resubmit 000be90 as a new PR, or do you create it, or do you just want the topic discussed first?)

[bterlson]

I'm sure there's a million better ways to do it, but the way I would do it is to something like

1. git checkout editorial
2. git checkout -b some-branch-name
3. git checkout editorial
4. git reset --hard HEAD~1
5. git push -f /editorial (this will update this PR)
6. git push /some-branch-name (and send a new PR for this)

[claudepache]

I am personally fine with the conceptual model where internal methods are internal slots with function-like values

Note that [[RegExpMatcher]] contains a procedure, but is (rightfully) an internal slot. My guess is that we are spoiled by the JS object model where the distinction between methods and properties is blurred. :-P

[jmdyck]

Okay, done, I think.

[bterlson]

Looks like you've done it, thanks!

@jmdyck are you interested in doing a follow-up pr for removal of "the value of"? I can put one up too if you'd like, no worries.

[jmdyck]

I'll think about it, but I've got another PR to do first.

[domenic]

<3 yaaaay this makes specs so much more readable. Going to go change streams now.