Normative: Add Intl.Segmenter #553

gibson042 · 2021-03-10T07:38:42Z

@leobalter

FrankYFTang · 2021-05-03T13:41:06Z

Should the "2 Conformance" https://tc39.es/ecma402/#conformance also be changed for Intl.Segmenter?

FrankYFTang · 2021-12-09T03:20:03Z

I suggest you also add

    <li>
      <a href="https://www.unicode.org/reports/tr29/">Unicode Standard Annex 29- Unicode Text Segmentation</a>
    </li>

to the end of normative-references.html
And also mayb consider listing
Common Locale Data Repository (available at http://cldr.unicode.org)
and
International Components for Unicode https://unicode-org.github.io/icu-docs/
Since that two are also mentioned in the proposal.

gibson042 · 2021-12-10T01:32:24Z

Thank you @FrankYFTang. I have included UAX 29, but not CLDR or ICU because references to those are intentionally non-normative.

gibson042 · 2021-12-14T23:42:02Z

@ryzokuken Could I get a review from you as well?

ryzokuken · 2021-12-15T07:36:27Z

@gibson042 absolutely! Sorry for the delay, but I thought this would be an even larger diff. On it.

ryzokuken

Overall LGTM, with a few comments inline. Two main comments:

Would you like to switch to the new structured arguments syntax?
The AOs are interleaved all over the spec and I don't see a compelling reason for that. Would you mind putting the AO section at the top with all the AOs in it?

ryzokuken · 2022-01-05T09:55:13Z

spec/segmenter.html

+        1. Let _internalSlotsList_ be &laquo; [[InitializedSegmenter]], [[Locale]], [[SegmenterGranularity]] &raquo;.
+        1. Let _segmenter_ be ? OrdinaryCreateFromConstructor(NewTarget, *"%Segmenter.prototype%"*, _internalSlotsList_).


Any reason why this is a single-use variable and not inline?

If you're referring internalSlotsList, it's for the value of naming what is otherwise a potentially confusing argument (especially when the list of slots exceeds three or four items) using a convention that is already fairly common throughout ECMA-262 and ECMA-402.

I would actually support a followup making it universal in ECMA-402, ideally using a table-based approach like OrdinaryFunctionCreate and BoundFunctionCreate and ModuleNamespaceCreate:

Suggested change

1. Let _internalSlotsList_ be « [[InitializedSegmenter]], [[Locale]], [[SegmenterGranularity]] ».

1. Let _segmenter_ be ? OrdinaryCreateFromConstructor(NewTarget, *"%Segmenter.prototype%"*, _internalSlotsList_).

1. Let _internalSlotsList_ be the internal slots listed in <emu-xref href="#table-segment-iterator-instance-slots"></emu-xref>.

1. Let _segmenter_ be ? OrdinaryCreateFromConstructor(NewTarget, *"%Segmenter.prototype%"*, _internalSlotsList_).

SGTM, thanks.

Captured at #649

ryzokuken · 2022-01-05T10:14:12Z

spec/segmenter.html

+    </emu-clause>
+  </emu-clause>
+
+  <emu-clause id="sec-intl-segmenter-abstracts">


In ECMA-402, the abstract operations for any object are at the top, before the constructor. Would you like to reorder these to be more consistent?

As with CreateSegmentsObject, I think positioning operations below their use makes for better (specifically more linear) consumption of the spec. I'm willing to change this, but would rather update other sections to follow its pattern. Thoughts?

ryzokuken · 2022-01-05T11:56:15Z

spec/segmenter.html

+      </p>
+
+      <p>
+        The value of the [[RelevantExtensionKeys]] internal slot is &laquo; &raquo;.


Do you think this would change at some point? If not, why not just hardcode the empty list in the constructor and get rid of this?

Just noticed that other constructors follow this pattern too, so you're definitely in the right here. Just generally curious if this is better than just hardcoding an empty list.

I think it is better than hardcoding, because https://tc39.es/ecma402/#sec-internal-slots documents a [[RelevantExtensionKeys]] for each service constructor.

Makes sense.

ryzokuken · 2022-01-05T14:57:14Z

spec/segmenter.html

+      </ul>
+
+      <emu-clause id="sec-%segmentsprototype%.containing">
+        <h1>%SegmentsPrototype%.containing ( _index_ )</h1>


Why this and not Segmenter.prototype.containing like everywhere else?

containing is not a method of Segmenter instances (the values returned from new Intl.Segmenter(…), whose prototype is %Segmenter.prototype%, which can be accessed as the initial value of Intl.Segmenter.prototype), but rather of Segments instances (the values returned from segmenter.segment(str), whose prototype is the different object %SegmentsPrototype%, for which there is no simple access path available to ECMAScript code).

sorry, I mistyped, I meant Segments.prototype.containing, didn't know that this wasn't valid.

ryzokuken · 2022-01-05T15:33:09Z

spec/segmenter.html

+      A Segments instance is an object that represents the segments of a specific string, subject to the locale and options of its constructing Intl.Segmenter instance.
+    </p>
+
+    <emu-clause id="sec-createsegmentsobject" aoid="CreateSegmentsObject">


It seems a bit unusual that this AO it placed here, away from all other AOs, is there a strong reason to prefer this over the opposite?

I think there's a lot of value in positioning Create<Type> AOs as the first subsection of their <Type> section and following them with the description of the prototype they use, supporting a linear reading of the specification.

gibson042

Would you like to switch to the new structured arguments syntax?

Yes, but I think I'd prefer that change after merge, to minimize divergence from the text of the proposal (which preceded structured headers).

The AOs are interleaved all over the spec and I don't see a compelling reason for that. Would you mind putting the AO section at the top with all the AOs in it?

How strongly do you feel about this? I have a fairly strong preference for this pattern (with the compelling reason being "better readability for linear spec consumption"), and would like to update the rest of ECMA-402 accordingly as soon as possible. But I'm willing to revert this to the existing pattern if you think that will be contentious or take too long.

gibson042 · 2022-01-05T21:30:28Z

spec/segmenter.html

+        1. Let _internalSlotsList_ be &laquo; [[InitializedSegmenter]], [[Locale]], [[SegmenterGranularity]] &raquo;.
+        1. Let _segmenter_ be ? OrdinaryCreateFromConstructor(NewTarget, *"%Segmenter.prototype%"*, _internalSlotsList_).


If you're referring internalSlotsList, it's for the value of naming what is otherwise a potentially confusing argument (especially when the list of slots exceeds three or four items) using a convention that is already fairly common throughout ECMA-262 and ECMA-402.

I would actually support a followup making it universal in ECMA-402, ideally using a table-based approach like OrdinaryFunctionCreate and BoundFunctionCreate and ModuleNamespaceCreate:

Suggested change

1. Let _internalSlotsList_ be « [[InitializedSegmenter]], [[Locale]], [[SegmenterGranularity]] ».

1. Let _segmenter_ be ? OrdinaryCreateFromConstructor(NewTarget, *"%Segmenter.prototype%"*, _internalSlotsList_).

1. Let _internalSlotsList_ be the internal slots listed in <emu-xref href="#table-segment-iterator-instance-slots"></emu-xref>.

1. Let _segmenter_ be ? OrdinaryCreateFromConstructor(NewTarget, *"%Segmenter.prototype%"*, _internalSlotsList_).

gibson042 · 2022-01-05T23:03:33Z

spec/segmenter.html

+      </p>
+
+      <p>
+        The value of the [[RelevantExtensionKeys]] internal slot is &laquo; &raquo;.


I think it is better than hardcoding, because https://tc39.es/ecma402/#sec-internal-slots documents a [[RelevantExtensionKeys]] for each service constructor.

gibson042 · 2022-01-05T23:17:22Z

spec/segmenter.html

+      A Segments instance is an object that represents the segments of a specific string, subject to the locale and options of its constructing Intl.Segmenter instance.
+    </p>
+
+    <emu-clause id="sec-createsegmentsobject" aoid="CreateSegmentsObject">


I think there's a lot of value in positioning Create<Type> AOs as the first subsection of their <Type> section and following them with the description of the prototype they use, supporting a linear reading of the specification.

gibson042 · 2022-01-05T23:27:33Z

spec/segmenter.html

+      </ul>
+
+      <emu-clause id="sec-%segmentsprototype%.containing">
+        <h1>%SegmentsPrototype%.containing ( _index_ )</h1>


containing is not a method of Segmenter instances (the values returned from new Intl.Segmenter(…), whose prototype is %Segmenter.prototype%, which can be accessed as the initial value of Intl.Segmenter.prototype), but rather of Segments instances (the values returned from segmenter.segment(str), whose prototype is the different object %SegmentsPrototype%, for which there is no simple access path available to ECMAScript code).

gibson042 · 2022-01-05T23:30:55Z

spec/segmenter.html

+    </emu-clause>
+  </emu-clause>
+
+  <emu-clause id="sec-intl-segmenter-abstracts">


As with CreateSegmentsObject, I think positioning operations below their use makes for better (specifically more linear) consumption of the spec. I'm willing to change this, but would rather update other sections to follow its pattern. Thoughts?

ryzokuken · 2022-01-06T07:26:24Z

@gibson042

How strongly do you feel about this? I have a fairly strong preference for this pattern (with the compelling reason being "better readability for linear spec consumption"), and would like to update the rest of ECMA-402 accordingly as soon as possible. But I'm willing to revert this to the existing pattern if you think that will be contentious or take too long.

Honestly, I'm not sure anymore. Your rationale sounds great to me, but there's also the benefit of keeping things organized in a single location, maybe this is especially notable here because the proposal introduces three types simultaneously. Perhaps the better judge of this would be the implementers?

@FrankYFTang @Constellation does this new pattern of organizing AOs seem helpful to you? Do you think it correctly corresponds to how you consume the spec? If so, I have no reservations against it.

@gibson042 should we also solicit feedback from the 262 editors here?

gibson042 · 2022-01-06T16:49:54Z

should we also solicit feedback from the 262 editors here?

Possibly, but 262 itself is inconsistent (e.g., Map follows the pattern I'm proposing here but ArrayBuffer is more like the rest of 402, and WeakRef is in between them).

sffc · 2022-01-13T20:56:33Z

2022-01-13 discussion: https://github.com/tc39/ecma402/blob/master/meetings/notes-2022-01-13.md#normative-add-intlsegmenter-553

ryzokuken · 2022-01-24T14:35:17Z

@gibson042 can you please make a PR for the editorial changes to 402 so I can merge this?

gibson042 · 2022-01-24T17:48:54Z

@ryzokuken done: #650

Proposal moved to stage 4, and was merged in Ecma402: tc39/proposals@24bdab7 tc39/ecma402#553

* Drop Intl.displayNames v2 proposal, merged in Ecma402 Proposal reached stage 4, was integrated in Ecma402 and now returns a 404: tc39/proposals@f4378e1 tc39/ecma402#622 * Drop Intl.Segmenter proposal, merged in Ecma402 Proposal moved to stage 4, and was merged in Ecma402: tc39/proposals@24bdab7 tc39/ecma402#553

gibson042 mentioned this pull request Mar 10, 2021

Advance to stage 4 tc39/proposal-intl-segmenter#114

Closed

sffc mentioned this pull request May 8, 2021

Intl.breakIterator #60

Closed

sffc linked an issue May 8, 2021 that may be closed by this pull request

Intl.breakIterator #60

Closed

ryzokuken added normative stage 4 labels Jul 22, 2021

gibson042 added 4 commits October 25, 2021 01:01

Normative: Add Intl.Segmenter

11b8a1d

Editorial: Fix lint issues

624ba20

Normative: Update to match proposal text

0460f1b

Editorial: Fix lint issues

e767be7

gibson042 force-pushed the 2021-03-Segmenter branch from 05e9865 to e767be7 Compare October 25, 2021 06:07

Editorial: Add missing ECMA-262 biblio term for %Object.prototype%

fb402a3

gibson042 added a commit to gibson042/proposal-intl-segmenter that referenced this pull request Oct 25, 2021

Normative: Sync with ECMA-402 PR

dad3e48

tc39/ecma402#553

gibson042 mentioned this pull request Oct 25, 2021

Normative: Sync with ECMA-402 PR tc39/proposal-intl-segmenter#146

Merged

gibson042 added a commit to tc39/proposal-intl-segmenter that referenced this pull request Oct 25, 2021

Normative: Sync with ECMA-402 PR

346f927

tc39/ecma402#553

Normative: Include UAX 29 in Normative References

8aabfe2

gibson042 added 2 commits December 15, 2021 15:13

Merge branch 'master' into 2021-03-Segmenter

8f55445

Meta: Fix biblio

abae4dd

ryzokuken approved these changes Jan 5, 2022

View reviewed changes

gibson042 commented Jan 5, 2022

View reviewed changes

Editorial: Define service constructor slots in the conventional order

afe07bb

gibson042 mentioned this pull request Jan 24, 2022

OrdinaryCreateFromConstructor should be invoked consistently #649

Open

gibson042 mentioned this pull request Jan 24, 2022

Editorial: Linearize reading #650

Merged

ryzokuken merged commit aad9a02 into tc39:master Jan 24, 2022

tidoust added a commit to w3c/browser-specs that referenced this pull request Jan 25, 2022

Drop Intl.Segmenter proposal, merged in Ecma402

d83e10b

Proposal moved to stage 4, and was merged in Ecma402: tc39/proposals@24bdab7 tc39/ecma402#553

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Normative: Add Intl.Segmenter #553

Normative: Add Intl.Segmenter #553

gibson042 commented Mar 10, 2021

FrankYFTang commented May 3, 2021

FrankYFTang commented Dec 9, 2021

gibson042 commented Dec 10, 2021

gibson042 commented Dec 14, 2021

ryzokuken commented Dec 15, 2021

ryzokuken left a comment

ryzokuken Jan 5, 2022

gibson042 Jan 5, 2022

ryzokuken Jan 6, 2022

gibson042 Jan 24, 2022

ryzokuken Jan 5, 2022

gibson042 Jan 5, 2022

ryzokuken Jan 5, 2022

ryzokuken Jan 5, 2022

gibson042 Jan 5, 2022

ryzokuken Jan 6, 2022

ryzokuken Jan 5, 2022

gibson042 Jan 5, 2022

ryzokuken Jan 6, 2022

ryzokuken Jan 5, 2022

gibson042 Jan 5, 2022

gibson042 left a comment

gibson042 Jan 5, 2022

gibson042 Jan 5, 2022

gibson042 Jan 5, 2022

gibson042 Jan 5, 2022

gibson042 Jan 5, 2022

ryzokuken commented Jan 6, 2022

gibson042 commented Jan 6, 2022

sffc commented Jan 13, 2022

ryzokuken commented Jan 24, 2022

gibson042 commented Jan 24, 2022 •

edited

Loading

		1. Let _internalSlotsList_ be « [[InitializedSegmenter]], [[Locale]], [[SegmenterGranularity]] ».
		1. Let _segmenter_ be ? OrdinaryCreateFromConstructor(NewTarget, "%Segmenter.prototype%", _internalSlotsList_).

Normative: Add Intl.Segmenter #553

Normative: Add Intl.Segmenter #553

Conversation

gibson042 commented Mar 10, 2021

FrankYFTang commented May 3, 2021

FrankYFTang commented Dec 9, 2021

gibson042 commented Dec 10, 2021

gibson042 commented Dec 14, 2021

ryzokuken commented Dec 15, 2021

ryzokuken left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

gibson042 left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ryzokuken commented Jan 6, 2022

gibson042 commented Jan 6, 2022

sffc commented Jan 13, 2022

ryzokuken commented Jan 24, 2022

gibson042 commented Jan 24, 2022 • edited Loading

gibson042 commented Jan 24, 2022 •

edited

Loading