Editorial: more punctuation consistification issues

[domenic]

Abstract operation, internal method, and job declarations use variable spacing in their parameter lists. Sometimes Name(foo, bar), sometimes Name( foo, bar ), and sometimes Name ( foo, bar ), along with other variations that are presumably typos.

Record creation of various types uses different spacing as well: Record{[[foo]]: bar}, Record {[[foo]]: bar}, Record { [[foo]]: bar }, etc. Be sure not to just search for Record though; it applies to e.g. property attributes, "the record", and other record types like PropertyDescriptor or Completion.

Abstract operation/internal method/job declarations use a variety of ways of declaring optional parameters. Sometimes the comma is inside the brackets (Map.prototype.forEach), sometimes outside (Call, Construct), and most of the time optional arguments are not bracketed at all (CreateMutableBinding).

[ljharb]

Is there a clear preference that we want? I'm happy to make everything consistent, but unless I'm told "pick your favorite" i'd rather go with the consensus.

[ljharb]

Is there a clear preference that we want? I'm happy to make everything consistent, but unless I'm told "pick your favorite" i'd rather go with the consensus.

[annevk]

From HTML:

Abstract operation definition

StructuredSerializeInternal ( value, forStorage [ , memory ] )

Records

{ [[Type]]: "Number", [[NumberData]]: value.[[NumberData]] }

Record { [[Key]], [[Value]] }

Abstract operation invocation

Let serializedKey be ? StructuredSerializeInternal(entry.[[Key]], forStorage, memory).

The above generally reads well to me and is what @domenic advocated we use in WHATWG if I remember correctly. Streams uses the same style.

[annevk]

From HTML:

Abstract operation definition

StructuredSerializeInternal ( value, forStorage [ , memory ] )

Records

{ [[Type]]: "Number", [[NumberData]]: value.[[NumberData]] }

Record { [[Key]], [[Value]] }

Abstract operation invocation

Let serializedKey be ? StructuredSerializeInternal(entry.[[Key]], forStorage, memory).

The above generally reads well to me and is what @domenic advocated we use in WHATWG if I remember correctly. Streams uses the same style.

[ljharb]

To rephrase and make sure I'm reading properly:

• Abstract ops: <operation name><space>(<space><argument list separated by ",<space>"><space>)
• Records as pairs: {<space><pair of "<slot name>:<space><slot value>" separated by ",<space>"><space>}
• Records as a list of a single keypair: Record<space>{<space><slot name>,<space><slot value><space>}
• abstract op invocation: <operation name>(<argument list separated by ",<space>">), prefixed by ?<space> or !<space> as needed
• end algorithm steps with <.>

?

That makes sense to me; I'll begin to prepare a patch.

[ljharb]

To rephrase and make sure I'm reading properly:

• Abstract ops: <operation name><space>(<space><argument list separated by ",<space>"><space>)
• Records as pairs: {<space><pair of "<slot name>:<space><slot value>" separated by ",<space>"><space>}
• Records as a list of a single keypair: Record<space>{<space><slot name>,<space><slot value><space>}
• abstract op invocation: <operation name>(<argument list separated by ",<space>">), prefixed by ?<space> or !<space> as needed
• end algorithm steps with <.>

?

That makes sense to me; I'll begin to prepare a patch.

[annevk]

That looks correct, except for <record name>. At least the example I quoted has "Record" there literally, linking to https://tc39.github.io/ecma262/#sec-list-and-record-specification-type. And looking at that a bit more it seems we're inconsistent in whether to precede a Record with such a literal.

[annevk]

That looks correct, except for <record name>. At least the example I quoted has "Record" there literally, linking to https://tc39.github.io/ecma262/#sec-list-and-record-specification-type. And looking at that a bit more it seems we're inconsistent in whether to precede a Record with such a literal.

[ljharb]

Got it, updated my rephrasing.

[ljharb]

Got it, updated my rephrasing.

[ljharb]

I opened #1143 to handle most of it; I couldn't find a practical regex to use to locate "abstract op invocations" with improper spacing.

[ljharb]

I opened #1143 to handle most of it; I couldn't find a practical regex to use to locate "abstract op invocations" with improper spacing.

[bterlson]

This is all fine by me except records, which don't need space between the record name and {. I don't think it helps readability and can definitely hurt depending on where line breaks end up. Yes ecmarkup could replace such occurrences with nbsp but it won't help in my editor (ecma262 source text does not use manual line wrapping).

[bterlson]

This is all fine by me except records, which don't need space between the record name and {. I don't think it helps readability and can definitely hurt depending on where line breaks end up. Yes ecmarkup could replace such occurrences with nbsp but it won't help in my editor (ecma262 source text does not use manual line wrapping).

[bterlson]

Also, if there is an effort at a broad alignment, make sure to include the directed operation syntax .

[bterlson]

Also, if there is an effort at a broad alignment, make sure to include the directed operation syntax .

[ljharb]

@bterlson do you mean only for named records, or also for Record { vs Record{?

[ljharb]

@bterlson do you mean only for named records, or also for Record { vs Record{?

[ljharb]

With #1143, and a number of previous PRs, the only remaining item for this issue might be spacing around abstract operation invocations. Can someone review, and confirm/correct?

[ljharb]

With #1143, and a number of previous PRs, the only remaining item for this issue might be spacing around abstract operation invocations. Can someone review, and confirm/correct?

[jmdyck]

the only remaining item for this issue might be spacing around abstract operation invocations.

It looks like that was taken care of in early 2016 (e.g., 2fb8d08 and 690bcd9).

I think this issue can be closed.

[jmdyck]

the only remaining item for this issue might be spacing around abstract operation invocations.

It looks like that was taken care of in early 2016 (e.g., 2fb8d08 and 690bcd9).

I think this issue can be closed.