Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Editorial: Refactor SetNumberFormatDigitOptions #575

Merged
merged 13 commits into from
Oct 12, 2021
Merged

Conversation

sffc
Copy link
Contributor

@sffc sffc commented May 15, 2021

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.

@sffc sffc requested a review from ryzokuken May 15, 2021 23:47
sffc added a commit to tc39/proposal-intl-numberformat-v3 that referenced this pull request May 17, 2021
Copy link
Member

@ryzokuken ryzokuken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The difference becomes apparent in NFv3.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, I don't feel that strongly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I resolved this a bit by denesting the hasSd construction.

@anba
Copy link
Contributor

anba commented May 19, 2021

  1. 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:

  1. If mnsd is not undefined or mxsd is not undefined, set hasSd to true.
  2. Else, set hasSd to false.

@ryzokuken
Copy link
Member

@sffc could you please address the review?

Copy link
Contributor Author

@sffc sffc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

How's this?

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

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I resolved this a bit by denesting the hasSd construction.

Copy link
Member

@ryzokuken ryzokuken left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just two editorial questions, everything else LGTM.

Comment on lines 25 to 26
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*.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Because I find it more readable to write

  1. If condition, set a to true; else, set a to false.
  2. If condition, set b to true; else, set b to false.
  3. If condition, set c to true; else, set c to false.
  4. If condition, set d to true; else, set d to false.

than to write

  1. If condition, set a to true.
  2. Else, set a to false.
  3. If condition, set b to true.
  4. Else, set b to false.
  5. If condition, set c to true.
  6. Else, set c to false.
  7. If condition, set d to true.
  8. Else, set d to false.

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

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@syg @anba thoughts?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ping @anba @syg

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

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*.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same as above.

@sffc 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
@gibson042
Copy link
Contributor

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>

Copy link
Contributor

@gibson042 gibson042 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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~

1. Set _hasFd_ to *true*.
1. Else,
1. Set _hasFd_ to *false*.
1. Let _needSd_ be _hasSd_.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
sffc and others added 3 commits August 16, 2021 11:18
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
spec/numberformat.html Outdated Show resolved Hide resolved
@sffc
Copy link
Contributor Author

sffc commented Aug 16, 2021

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 Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
spec/numberformat.html Outdated Show resolved Hide resolved
Comment on lines 63 to 64
1. If _needSd_ or _needFd_, then
1. If _hasSd_, then
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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~.

sffc and others added 2 commits August 30, 2021 14:03
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
@sffc
Copy link
Contributor Author

sffc commented Sep 24, 2021

Ping

@ryzokuken
Copy link
Member

@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.

Copy link
Contributor

@gibson042 gibson042 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.:

  • mnfdDefaultminFractionalDigitsDefault
  • mxfdDefaultmaxFractionalDigitsDefault
  • mnidminIntegerDigits
  • hasSdconstrainsSignificantDigits

spec/numberformat.html Outdated Show resolved Hide resolved
Co-authored-by: Richard Gibson <richard.gibson@gmail.com>
@ryzokuken
Copy link
Member

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

@ryzokuken
Copy link
Member

fwiw, nvm fails on the CI.

/cc @ljharb any idea what's wrong?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
editorial Involves an editorial fix
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

5 participants