ICU-23424 mf2: API improvements for composed functions

[srl295]

This does not depend on #4041 but only deals with the API improvements.

• FunctionContext.getCalledFunctionName()
• FunctionContext.withLocale()
• FunctionContext.getStandardFunction()

Also,

• internal improvements to support the above
• FunctionValue.getFunctionName() now returns a FunctionName

Checklist

• Required: Issue filed: ICU-23424
• Required: The PR title must be prefixed with a JIRA Issue number. Example: "ICU-NNNNN Fix xyz"
• Required: Each commit message must be prefixed with a JIRA Issue number. Example: "ICU-NNNNN Fix xyz"
• Issue accepted (done by Technical Committee after discussion)
• Tests included, if applicable
• API docs and/or User Guide docs changed or added, if applicable
• Approver: Feel free to merge on my behalf

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• icu4c/source/i18n/unicode/messageformat2_function_registry.h is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[mihnita]

I think that in the last TC meeting the agreed direction was to allow the overriding of the custom functions AND/OR to allow the use of function contexts to override the locale based on function name.

And (if my memory serves me well) Matt this was supposed to think if the function context was an acceptable solution (makes sense, since this function context idea was new it was hard to judge "on the spot").

If we are going in that direction there is no need for any custom functions or function overrides.
So all the APIs "tinkering" with the function registries are not needed.

Am I understanding this correctly?

[srl295]

I think that in the last TC meeting the agreed direction was to allow the overriding of the custom functions AND/OR to allow the use of function contexts to override the locale based on function name.

And (if my memory serves me well) Matt this was supposed to think if the function context was an acceptable solution (makes sense, since this function context idea was new it was hard to judge "on the spot").

I sent a slack message — I'd like to understand the new function context idea in enough detail to have an API proposal. Can you help sketch it out?

If we are going in that direction there is no need for any custom functions or function overrides. So all the APIs "tinkering" with the function registries are not needed.
Am I understanding this correctly?

No tinkering here. This PR (#4054) is so that overriding can still call the existing functions— otherwise the caller needs to reimplement all of them, from the ground up, without access to internals. This doesn't give access to internals, but allows composition, in the style of f(g(x)) or maybe f(g(x)+K)

[srl295]

I think that in the last TC meeting the agreed direction was to allow the overriding of the custom functions AND/OR to allow the use of function contexts to override the locale based on function name.
And (if my memory serves me well) Matt this was supposed to think if the function context was an acceptable solution (makes sense, since this function context idea was new it was hard to judge "on the spot").

I sent a slack message — I'd like to understand the new function context idea in enough detail to have an API proposal. Can you help sketch it out?

If we are going in that direction there is no need for any custom functions or function overrides. So all the APIs "tinkering" with the function registries are not needed.
Am I understanding this correctly?

No tinkering here. This PR (#4054) is so that overriding can still call the existing functions— otherwise the caller needs to reimplement all of them, from the ground up, without access to internals. This doesn't give access to internals, but allows composition, in the style of f(g(x)) or maybe f(g(x)+K)

@mihnita i've updated my API proposal.

[jira-pull-request-webhook]

Notice: the branch changed across the force-push!

• icu4c/source/i18n/unicode/messageformat2_function_registry.h is different

View Diff Across Force-Push

~ Your Friendly Jira-GitHub PR Checker Bot

[jira-pull-request-webhook]

Hooray! The files in the branch are the same across the force-push. 😃

~ Your Friendly Jira-GitHub PR Checker Bot

[mihnita]

i've updated my API proposal

Thank you, but I am afraid I am still confused.

We go ahead with API proposals that I don't think are the right way to solve the problem.
We discussed that, and I thought there was some agreement on it.

If we have a way to set a locale per function, there is no need to override the function at all, and there is no need to do function composition at all.
And, even better, for the problem we try to solve (locale override) does not require the users to implement custom functions at all, just call some extra set methods on the message builder.

Once we get to APIs we switch to "how to expose solution X", bypassing the whole discussion on what we try to solve, what are the options, pros and cons, which option we choose, why.

So I think the friction I see here (me reviewing these PRs) come from 2 causes:

1. a jump to implementation without first having an agreement if it is the right solution or not
2. not considering the Java APIs, which should be in sync with the C++ ones

I think that number 1 would benefit from a design document. I am fine to start it, list the options I'm aware or.

For number 2, I agree that it would have been ideal to keep them in sync from the get go.
But C++ was way behind, and now it's playing catch-up.
It is great that it does, and I understand that it might require some changes in the Java APIs. But we have to check what APIs are already out of "tech preview".

For example the function context does not exist in the Java APIs.
And it does not really exist in the spec. It is mentioned 4 times, without being defined, in the area explaining how an implementation should behave.

And C++ implementations also benefits from the fact that it is happening with the spec already finalized. Most of the Java APIs were exposed before we had a final spec.

But I think that rushing in with APIs approvals from TC without 1 and 2 is not a good way to proceed.