Editorial: Refactor SetNumberFormatDigitOptions by sffc · Pull Request #575 · tc39/ecma402

sffc · 2021-05-15T23:47:01Z

This is an editorial change intended to re-structure the SetNumberFormatDigitOptions abstract operation to reduce diffs in the NumberFormat v3 proposal.

@ryzokuken, you've worked extensively on this abstract operation before, so I would like you to review it to make sure that it is, indeed, editorial.

ryzokuken

Great change, it makes everything so much simpler editorially! I wish it was here before #471! One minor comment about simplifying one of the branches.

ryzokuken · 2021-05-19T11:32:59Z

spec/numberformat.html

+            1. Let _mxsd_ be ? DefaultNumberOption(_mxsd_, _mnsd_, 21, 21).
+            1. Set _intlObj_.[[MinimumSignificantDigits]] to _mnsd_.
+            1. Set _intlObj_.[[MaximumSignificantDigits]] to _mxsd_.
+          1. Else,


Since _needSd_ is the same as _hasSd_, why do we need this?

Maybe it is there just to align this with the next condition? Does that achieve much though?

The difference becomes apparent in NFv3.

@sffc ah, okay, I suspected so... perhaps it is okay to drop these additional conditions here and re-add them in NFv3?

I have a slight preference to keep the extra variables because (1) they more clearly signify intent and (2) they reduce the size of the NFv3 diff, but I'm willing to change it if you feel more strongly.

No, I don't feel that strongly.

I resolved this a bit by denesting the hasSd construction.

anba · 2021-05-19T17:20:16Z

Let hasSd be mnsd is not undefined or mxsd is not undefined.

ECMASpeak doesn't have implicit to boolean conversions in this context. So this needs to be more like:

If mnsd is not undefined or mxsd is not undefined, set hasSd to true.

Else, set hasSd to false.

ryzokuken · 2021-06-07T09:18:15Z

@sffc could you please address the review?

sffc

How's this?

sffc · 2021-06-18T04:15:12Z

spec/numberformat.html

+            1. Let _mxsd_ be ? DefaultNumberOption(_mxsd_, _mnsd_, 21, 21).
+            1. Set _intlObj_.[[MinimumSignificantDigits]] to _mnsd_.
+            1. Set _intlObj_.[[MaximumSignificantDigits]] to _mxsd_.
+          1. Else,


I resolved this a bit by denesting the hasSd construction.

ryzokuken

Just two editorial questions, everything else LGTM.

ryzokuken · 2021-06-18T05:20:22Z

spec/numberformat.html

+        1. If _mnsd_ is not *undefined* or _mxsd_ is not *undefined*, set _hasSd_ to *true*; else, set _hasSd_ to *false*.
+        1. If _mnfd_ is not *undefined* or _mxfd_ is not *undefined*, set _hasFd_ to *true*; else, set _hasFd_ to *false*.


Any reason why both of these conditions are on a single line instead of being split across two?

Because I find it more readable to write

If condition, set a to true; else, set a to false.

If condition, set b to true; else, set b to false.

If condition, set c to true; else, set c to false.

If condition, set d to true; else, set d to false.

than to write

If condition, set a to true.

Else, set a to false.

If condition, set b to true.

Else, set b to false.

If condition, set c to true.

Else, set c to false.

If condition, set d to true.

Else, set d to false.

But if you disagree, or if my syntax is not normal for the spec, I will change it.

I agree that it's more readable, but I am unsure if (1) this is a spec convention (2) it even matters.

Maybe we can ask the 262 editors about it?

@syg @anba thoughts?

Ping @anba @syg

Both alternatives are valid and are used in ECMA-262 and ECMA-402.

I think as a rule of thumb, I normally just try to follow the usage in the surrounding code resp. operations. Except when the condition is overly long or in a deeply nested step, so that the short form would either be rendered across multiple lines or when readability suffers.

ryzokuken · 2021-06-18T05:20:54Z

spec/numberformat.html

+        1. If _mnsd_ is not *undefined* or _mxsd_ is not *undefined*, set _hasSd_ to *true*; else, set _hasSd_ to *false*.
+        1. If _mnfd_ is not *undefined* or _mxfd_ is not *undefined*, set _hasFd_ to *true*; else, set _hasFd_ to *false*.
+        1. Let _needSd_ be _hasSd_.
+        1. If not _hasSd_ and _notation_ is not *"compact"*, set _needFd_ to *true*; else, set _needFd_ to *false*.


Same as above.

gibson042 · 2021-08-15T19:55:35Z

Since you're making changes to SetNumberFormatDigitOptions, can you also improve its description and eliminate the initial assertion steps by adopting a structured header (cf. #594)?

    <emu-clause id="sec-setnfdigitoptions" type="abstract operation">
      <h1>
        SetNumberFormatDigitOptions (
          _intlObj_: an Object,
          _options_: an Object,
          _mnfdDefault_: a Number,
          _mxfdDefault_: a Number,
          _notation_: a String,
        )
      </h1>
      <dl class="header">
        <dt>description</dt>
        <dd>It [description of what it does].</dd>
      </dl>
      <emu-alg>…</emu-alg>

gibson042

This change appears to be normative: https://jsfiddle.net/x0jq9drc/

Example observable impact:
SetNumberFormatDigitOptions(intlObj, {maximumFractionDigits: 0}, 0, 3, "compact")

 [[MinimumIntegerDigits]]: 1
-[[RoundingType]]: ~fractionDigits~
-[[MinimumFractionDigits]]: 0
-[[MaximumFractionDigits]]: 0
+[[RoundingType]]: ~compactRounding~

gibson042 · 2021-08-15T18:13:13Z

spec/numberformat.html

+          1. Set _hasFd_ to *true*.
+        1. Else,
+          1. Set _hasFd_ to *false*.
+        1. Let _needSd_ be _hasSd_.


What is the motivation for realiasing hasSd rather than continuing to use it directly?

I like the parallelism between [has/need]Fd with [has/need]Sd.

Also, in NumberFormat v3, needSd no longer equals hasSd. I could merge the variables for now, but doing so will increase the diff relative to NFv3.

spec/numberformat.html

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

spec/numberformat.html

sffc · 2021-08-16T18:04:22Z

Since you're making changes to SetNumberFormatDigitOptions, can you also improve its description and eliminate the initial assertion steps by adopting a structured header (cf. #594)?

Done!

This change appears to be normative: https://jsfiddle.net/x0jq9drc/

Example observable impact:
SetNumberFormatDigitOptions(intlObj, {maximumFractionDigits: 0}, 0, 3, "compact")
 [[MinimumIntegerDigits]]: 1
-[[RoundingType]]: ~fractionDigits~
-[[MinimumFractionDigits]]: 0
-[[MaximumFractionDigits]]: 0
+[[RoundingType]]: ~compactRounding~

Your JSFiddle is outstanding! I made one diff in dd7d0cf and managed to make your test case pass. Thank you so much! (Is it possible to get something like this into Test262? @ryzokuken)

spec/numberformat.html

gibson042 · 2021-08-16T22:31:36Z

spec/numberformat.html

+        1. If _needSd_ or _needFd_, then
+          1. If _hasSd_, then


Suggested change

1. If _needSd_ or _needFd_, then

1. If _hasSd_, then

1. If _needSd_ is *true* or _needFd_ is *true*, then

1. If _hasSd_ is *true*, then

But for that matter, this part seems hard to follow. Broader suggestion:

1. If _needSd_ is *false* and _needFd_ is *false*, then 1. Set _intlObj_.[[RoundingType]] to ~compactRounding~. 1. Else if _hasSd_ is *true*, then 1. Set _intlObj_.[[RoundingType]] to ~significantDigits~. 1. Else, 1. Set _intlObj_.[[RoundingType]] to ~fractionDigits~.

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

sffc · 2021-09-24T22:58:33Z

Ping

ryzokuken · 2021-09-26T17:29:12Z

@gibson042 could you please give this another review? It would be great to merge this in ASAP in order to move things along for NF v3.

gibson042

This looks good to me, and I confirmed that it does not include normative changes: https://jsfiddle.net/8teq2va9/

But as an editorial nit, I would like to see a followup that makes the parameter and alias names more clear. e.g.:

mnfdDefault → minFractionalDigitsDefault
mxfdDefault → maxFractionalDigitsDefault
mnid → minIntegerDigits
hasSd → constrainsSignificantDigits
…

spec/numberformat.html

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

ryzokuken · 2021-10-12T20:00:25Z

Looks like this is resolved! Thanks @gibson042 and @sffc. Merging this.

ryzokuken · 2021-10-12T20:02:59Z

fwiw, nvm fails on the CI.

/cc @ljharb any idea what's wrong?

Editorial: Refactor SetNumberFormatDigitOptions

0e3ce45

sffc requested a review from ryzokuken May 15, 2021 23:47

Additional refactor of [[RoundingType]]

902f943

sffc added a commit to tc39/proposal-intl-numberformat-v3 that referenced this pull request May 17, 2021

Update base according to tc39/ecma402/pull/575

4e9c277

ryzokuken approved these changes May 19, 2021

View reviewed changes

Review feedback

16601cf

sffc commented Jun 18, 2021

View reviewed changes

ryzokuken approved these changes Jun 18, 2021

View reviewed changes

sffc mentioned this pull request Jun 18, 2021

please fix the diff of SetNumberFormatDigitOptions tc39/proposal-intl-numberformat-v3#43

Closed

ryzokuken assigned sffc Jul 12, 2021

This was referenced Jul 14, 2021

Improve readability of SetNumberFormatDigitOptions tc39/proposal-intl-numberformat-v3#41

Closed

SetNumberFormatDigitOptions uses non-ECMASpeak syntax tc39/proposal-intl-numberformat-v3#51

Closed

ryzokuken added the editorial Involves an editorial fix label Jul 22, 2021

More review feedback

d9ef6c5

sffc requested a review from ryzokuken August 13, 2021 02:24

sffc added a commit to tc39/proposal-intl-numberformat-v3 that referenced this pull request Aug 13, 2021

Integrate latest changes to tc39/ecma402#575

9a9cec3

gibson042 requested changes Aug 15, 2021

View reviewed changes

sffc and others added 3 commits August 16, 2021 11:18

Apply suggestions from code review

68b8600

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

Apply suggestions from code review

e7d53bc

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

More Set -> Let

31b6a64

ptomato reviewed Aug 16, 2021

View reviewed changes

spec/numberformat.html Outdated Show resolved Hide resolved

sffc added 2 commits August 16, 2021 12:36

Let to -> Let be (thanks @ptomato!)

06e43cf

Fix logic

dd7d0cf

sffc force-pushed the nf-editorial branch from 94c8e4d to dd7d0cf Compare August 16, 2021 17:36

Adopt structured header

a3728b9

gibson042 reviewed Aug 16, 2021

View reviewed changes

sffc and others added 2 commits August 30, 2021 14:03

Apply suggestions from code review

ec70f0e

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

Additional feedback from @gibson042

5272398

sffc requested a review from gibson042 August 30, 2021 19:06

jugglinmike mentioned this pull request Sep 24, 2021

Basis for changes to SetNumberFormatDigitOptions abstract operation tc39/proposal-intl-numberformat-v3#70

Closed

ryzokuken approved these changes Sep 26, 2021

View reviewed changes

gibson042 approved these changes Oct 7, 2021

View reviewed changes

spec/numberformat.html Outdated Show resolved Hide resolved

Update spec/numberformat.html

cd6a927

Co-authored-by: Richard Gibson <richard.gibson@gmail.com>

ryzokuken merged commit d89c84f into master Oct 12, 2021

ryzokuken deleted the nf-editorial branch October 12, 2021 20:03

sffc mentioned this pull request Nov 30, 2021

Rebase diff for SetNumberFormatDigitOptions tc39/proposal-intl-numberformat-v3#80

Merged

sffc mentioned this pull request Apr 30, 2022

Intl.NumberFormat v3: Improve coverage of SetNumberFormatDigitOptions tc39/test262#3508

Open

romulocintra mentioned this pull request Jun 8, 2022

Increase coverage NFv3 - results of SetNumberFormatDigitOptions tc39/test262#3552

Draft

		1. If _mnsd_ is not undefined or _mxsd_ is not undefined, set _hasSd_ to true; else, set _hasSd_ to false.
		1. If _mnfd_ is not undefined or _mxfd_ is not undefined, set _hasFd_ to true; else, set _hasFd_ to false.

Conversation

sffc commented May 15, 2021

Uh oh!

ryzokuken left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

anba commented May 19, 2021

Uh oh!

ryzokuken commented Jun 7, 2021

Uh oh!

sffc left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ryzokuken left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

gibson042 commented Aug 15, 2021

Uh oh!

gibson042 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

sffc commented Aug 16, 2021

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

sffc commented Sep 24, 2021

Uh oh!

ryzokuken commented Sep 26, 2021

Uh oh!

gibson042 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

ryzokuken commented Oct 12, 2021