Motivation for a thin Amount versus protocol

[sffc]

I listed the following motivations for thin Amount today at TC39:

1. Represents a thing that many developers frequently have: a number with unit
   • By representing this, we can offer useful operations like i18n
2. Improves i18n by moving unit and precision to the data model
   • Fixes the "1.0 Stars" problem (different behavior in Intl.NumberFormat and Intl.PluralRules)
3. Prerequisite for the MessageFormat proposal (medium-term)
   • MF 2.0 is recommending this type of data model
4. Prerequisite for the Smart Units proposal (longer-term)
   • To prevent misuse of Intl APIs to do unit conversion

However, it wasn't clear to some delegates what this brings to the table versus a protocol-based approach: for example, adding support for passing { value: 123, unit: "meter" } to Intl.NumberFormat.prototype.format.

We have discussed passing objects to the format function in the past; for example, tc39/proposal-intl-numberformat-v3#1.

A couple key points for me for thin Amount, even without any other prototype functions:

1. Supports toLocaleString: this mechanism offers an onramp to i18n.
2. More discoverable: the protocol-based approach can be documented on Intl.NumberFormat.prototype.format and Intl.PluralRules.prototype.format, and we can make tutorials and things to advocate for this pattern, but we are putting aside a big opportunity to nudge developers to represent their data model in code.
3. Units and currencies can be validated: since we're moving these from constructor to format function, we lose the ability to validate early on. Concrete example: catch misspellings such as metre.
4. Ergonomic integration with Decimal is possible
5. More parallel with Temporal and the expectations developers have in the Temporal world.

Anything else to add here?

[ljharb]

The protocol-based approach can also support adding an Amount later, since such an Amount would have accessors for all the options anyways, and the Intl implementations would be updated to read its internal slots.

[sffc]

The protocol-based approach can also support adding an Amount later, since such an Amount would have accessors for all the options anyways, and the Intl implementations would be updated to read its internal slots.

I agree that a protocol could exist in parallel with Amount.

Do you have a concern about the protocol being unable to validate that the unit or currency is well-formed, which could cause the format function to throw an exception, something it currently does not do?

[ljharb]

new Amount throwing that same exception at an earlier time doesn't seem meaningfully different to that, to me.

[jasnell]

I think following the discussions today I'm personally leaning in favor of the Amount typed approach as opposed to the protocol model... tho I do appreciate that the protocol model is simpler from an implementation perspective. That said, I will admit that it's more of a style preference than a technical preference.

I think this question might be over indexing slightly on the side of the Intl formatting use case. There are other ways an Amount might be used such as providing context for arithmetic operations even if the API itself does not provide those operations itself. For example, I might (in userland) implement my own conversion operations and being able to rely on a strongly-typed Amount as opposed to a protocol would be more convenient...

function convert(amount: Amount, toUnit: string) {
  switch (amount.unit) {
    // ...
  }
}

This becomes ever so slightly less ergonomic with the protocol approach. Yes, I admit that it's VERY slight.. possibly so slight that some would argue it's not relevant ... so again, more style preference than functional. That said, the typed approach also has the advantage of immutability in the same manner as Temporal which shouldn't be discounted.