Repository navigation
Conversation
…ed function handlers for default functions
eemeli
added
functions
|
The relevant bit of code that is preventing my custom functions from working would seem to be this https://github.com/unicode-org/icu/blob/426cea1b85e82e632dc5c0b35c7d329c0eb4af7b/icu4c/source/i18n/messageformat2_formatter.cpp#L319 Since there is already a built-in function, it is always returned as-is and the custom function is never reached. I would think a simple-fix would be to return the custom function first if it happens to exist. But that may have unintended consequences. |
|
We had a very long thread about this on Slack. I think this should start with a design doc, or at least an issue, where we discuss pros and cons. |
| Implementations SHOULD provide mechanisms for users to | ||
| use user-defined _function handlers_ for _default functions_. |
There was a problem hiding this comment.
I think "SHOULD" is overdoing it. An implementation that doesn't provide such a mechanism is still conformant. I'd even avoid normative language here.
Also I'd probably allow for tailoring.
Note that I'm not arguing against this proposal. I have many times needed to override the behavior of the default implementation without explicitly using a namespaced replacement because I wanted to avoid creating messages that don't work without custom code installed.
There was a problem hiding this comment.
I will create a ticket and copy-paste there the discussion we had in Slack.
Not summarize it, but exact copy-paste, so there is no room for interpretation (other than what happens by default in written communication, in a chat, which I don't see as a good medium for well thought-out discutions :-)
As reported by Matt O'Conor on Slack:
And my reply:
This PR adds a new normative SHOULD to help avoid this problem recurring, as it should be possible to override default function handlers.