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.

Sign up for GitHub

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

Jump to bottom

Adding a :number offset option #926

Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Adding a :number offset option #926

Changes from all commits
Commits
Show all changes
4 commits
Select commit Hold shift + click to select a range
d10b5c9
Adding a :number offset option (#701)
mihnita Nov 7, 2024
89a48f7
Also support for :integer
mihnita Nov 7, 2024
5442a01
Make "optional" bold, for consistency
mihnita Nov 7, 2024
cd8ac68
Make the second bold, for consistency
mihnita Nov 7, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
23 changes: 22 additions & 1 deletion spec/registry.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -156,6 +156,8 @@ The following options and their values are required to be available on the funct
- ([digit size option](#digit-size-options))
- `maximumSignificantDigits`
- ([digit size option](#digit-size-options))
- `offset` **optional**
- ([digit size option](#digit-size-options), default: `0`)

If the _operand_ of the _expression_ is an implementation-defined type,
such as the _resolved value_ of an _expression_ with a `:number` or `:integer` _annotation_,
Expand Down Expand Up @@ -202,6 +204,12 @@ are encouraged to track development of these options during Tech Preview:
- `short` (default)
- `narrow`

The support for the `offset` option is optional.
The _resolved value_ of the _expression_ is determined by first subtracting the numeric value of `offset` from the _operand_,
and then resolving the _expression_ on the calculated value.
Comment on lines +208 to +209
Copy link
Collaborator

Choose a reason for hiding this comment

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

If the offset is applied to the numerical value of the resolved value and the offset option is also retained in the resolved options, doesn't that mean that it may get double-applied?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

This is the trouble with using :integer (or :number) for both formatting and selection.

So selection you need both the offset, and the original value.
Because you test the exact values against the original value, and the keywords against the value - offset.

But for formatting the value - offset is enough, and you can drop the offset from the resolved options.

Which means that if one does

.input {$count :integer offset=2}
.match $count
...

then the resolved value for $count should have the offset.

If we separated the :input / :number from :plural this would have an easy answer: :plural keeps the resolved value and resolved options "as is", and :integer resolves the value to the value - offset and remove the offset from the resolved values.

I am not pushing to revert that decision.
We voted and all.

But I am open to suggestions, because I am not sure what to do here.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Idea: leave the resolved value as is, and leave the offset in the resolved options.
Then the selection can see both.
And the "formatted value" (which we don't have a concept of, although it would be useful) can do the diff.

Trouble is that without the concept of "formatted value" we can't fully describe how the formatting works.

We have a section named "Numeric Value Selection and Formatting", but we don't seem to describe the formatting part at all.

Copy link
Member

Choose a reason for hiding this comment

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

My view is that the :offset affects selection and formatting (in parallel), but it is up to us to define in the :number specification for offset how successive :number offset values are combined — which does not prevent any other function options from combining in a different way.

Take the following:

.local $a {10 :number offset=2}
.local $b {$a :number offset=1}
.match $b
// please forgive any syntax errors

It is up to us to determine whether :number offset behaves like:

.local $a {10 :number :offset=3} // accumulates
or

.local $a {10 :number :offset=1} // replaces

I think we should have a general rule that unless otherwise stated, combinations of options do replacement, but that the specification for any given function option can override that behavior.

Implementations that don't support `offset` don't do any subtraction.
It is the same as subtracting the numeric value of `0`, the default value of `offset`.

##### Default Value of `select` Option

The value `plural` is the default for the option `select`
Expand Down Expand Up @@ -295,6 +303,8 @@ function `:integer`:
- ([digit size option](#digit-size-options), default: `1`)
- `maximumSignificantDigits`
- ([digit size option](#digit-size-options))
- `offset` **optional**
- ([digit size option](#digit-size-options), default: `0`)

If the _operand_ of the _expression_ is an implementation-defined type,
such as the _resolved value_ of an _expression_ with a `:number` or `:integer` _annotation_,
Expand Down Expand Up @@ -339,6 +349,12 @@ are encouraged to track development of these options during Tech Preview:
- `short` (default)
- `narrow`

The support for the `offset` option is optional.
The _resolved value_ of the _expression_ is determined by first subtracting the numeric value of `offset` from the _operand_,
and then resolving the _expression_ on the calculated value.
Implementations that don't support `offset` don't do any subtraction.
It is the same as subtracting the numeric value of `0`, the default value of `offset`.

##### Default Value of `select` Option

The value `plural` is the default for the option `select`
Expand Down Expand Up @@ -449,14 +465,19 @@ Number selection has three modes:
- `ordinal` selection matches the operand to explicit numeric keys exactly
followed by an ordinal rule category if there is no explicit match

When the selection mode is `plural` implementations can optionaly support
Copy link
Member

Choose a reason for hiding this comment

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

Why wouldn't ordinal work the same way?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

Why wouldn't ordinal work the same way?

I think we discussed it in the last meeting and nobody was able to come up with a use case for ordinals.

But ICU supports it.
So I am open to add it.

Copy link
Member

Choose a reason for hiding this comment

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

list = { Audrey, Bill, Carlos, David, Edna, Freda}

.local $first = {$list :get item=1}
.local $second = {$list :get item=2}
.local $user = {$list :get item=last}
.local $length = {$list :length}
.local $position = {$length :integer select=ordinal offset=2} 
.match $position
one {{After {$first} and {$second}, {$user} is {$position}st in line}}
two {{After {$first} and {$second}, {$user} is {$position}nd in line}}
... etc...

... but it's a pretty contrived use case...

the `offset` option ([digit size option](#digit-size-options), default: `0`).

When implementing [`MatchSelectorKeys(resolvedSelector, keys)`](/spec/formatting.md#resolve-preferences)
where `resolvedSelector` is the _resolved value_ of a _selector_
and `keys` is a list of strings,
numeric selectors perform as described below.

1. Let `exact` be the JSON string representation of the numeric value of `resolvedSelector`.
(See [Determining Exact Literal Match](#determining-exact-literal-match) for details)
1. Let `keyword` be a string which is the result of [rule selection](#rule-selection) on `resolvedSelector`.
1. Let `keyword` be a string which is the result of [rule selection](#rule-selection) on `resolvedSelector` minus the numeric value of the `offset` option.
Implementations that don't implement the `offset` option don't need to subtract anything.
It is the same as subtracting the numeric value of `0`, the default value of `offset`.
1. Let `resultExact` be a new empty list of strings.
1. Let `resultKeyword` be a new empty list of strings.
1. For each string `key` in `keys`:
Expand Down