Dynamic option values: do we want syntax like `{$arg func opt=$value}`?

[mihnita]

• Do we want syntax like {$arg func opt=$variable}? What are the use-cases?
• How can we make it work such that func is cached/memoized?
• Can $variable above be supplied by the application code as an argument to MessageFormat?
• Can $variable refer to another placeholder found in the same message?
• Can $variable refer to a local variable defined by the message?

[stasm]

@markusicu wrote in #230 (comment):

Do we need variables inside placeholder options? We have seen this before, but I don't remember a good use case being presented. I see one example that suggests using it for grammatical agreement, but I strongly suspect that managing grammatical agreement will require a second pass over the output of the whole "formatting" pass for a message; a second pass so that it can look at everything in context -- rather than trying to make one isolated placeholder agree with the input to another. So unless we have a really good use case for variables in options, let's leave them out.

[mihnita]

Comments migrated from the slides

---

Slides comment, Mihai Nita (@mihnita), 3:01 AM Apr 27

This completely "shutters" the difference between input and options.
There is no way to create a formatter and reuse it anymore.

The typical formatter use is this:

fmt = new XFormatter(options)
fmt.format(input1)
fmt.format(input2)
fmt.format(input3)

That is true not only for ICU, but also for JS:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Intl/DateTimeFormat/DateTimeFormat

If options depend on the input to message format then nothing is fixed anymore, and I can't create any formatter.

Imagine this:

Your card expires on {$exp :date year:$year day:$day month=$month hour=$hour minute=$min}!

There is no way to validate the options when you construct the formatter, or to create a formatter.

All I can do is keep the initial options in a bag and create a different formatter every time I get a some real input.
Maybe I can caches something, if I'm lucky.

===

TLDR: unless there is a really compelling use case for this, I think it is a bad idea to allow this.

---

Slides comment, Markus Scherer (@markusicu), 9:08 AM Apr 25

No optional whitespace here.
Require WS before each key=value pair and allow more than one WS there.
But no WS inside key=value.
Too many options just create gratuitous formatting differences and style discussions.

=====

It would be best if we didn't need variables/arguments in this position. Adds complexity.

[mihnita]

Meantime I think I’ve found a reasonable and correct use case for an argument in options:

mf = MessageFormat2.parse("I am {$height :measure system=$measurementSystem} tall");
mf.format({
    height = { value:1.75, unit:METER },
    measurementSystem: getMeasurementSystemPref()
})

ICU has in the works formatting measurement units, including conversion.
So I can say format {value:1.75 unit: METER} or {value:31 unit:CELSIUS} and ask to format it as imperial or metric.
And it will do conversion.
The input is correct, full information, value + unit.
And the measurement system really is an option.

If you don’t specify the measurement system it will take it from the locale.

But in general you might want to interrogate the OS (or the application) for preferences, it might be different than the locale one.
(that's the made-up getMeasurementSystemPref() call)

Resolution: I’m fine with $argument as a value for an option.

We might choose to add info in the registry to check and warn if something is a bad practice.
But not forbidden by design.
So I am OK with this. not an issue.

To think about:

• Although it might still be worth considering a different sigil for local variables…?
• And/or a way to “link” to another placeholder without a local variable.
• Registry specs for what is valid / not to configure this way

[markusicu]

So Mihai has shown a plausible use case for using an argument name as the value for an option. That might be a good solution for that use case. I can think of other solutions, but they are more clunky (providing a factory for the "measure" function biased with the measurement system) and/or require the message formatting to be done by an option with a setter for something that it should not need to know about.

[eemeli]

I've added the resolve-candidate label to this issue, as I think we may have reached consensus on it, to allow for option values that are determined by variable references. If you disagree with this, please remove the label and add a clarifying comment.

[romulocintra]

Consensus: Yes , with potential restrictions defined in function registry