Allow customizing argument resolver #304
Conversation
There was a problem hiding this comment.
This all seems reasonable to me, and allows for more programmatic integration with a Rust codebase. Since this is a design change I would like to get another reviewer on this to double check.
@nordzilla Would you mind looking at this briefly? The last commit includes an example that shows how to use it which I would appreciate your opinion on. You can also see the implementation of ArgumentResolver in fluent-bundle/src/resolver/scope.rs. You can track down the calls of it by searching for .resolve. I don't think you need to look at the first commit, since that's more of an implementation detail.
|
Oh and also thanks for the PR :) |
This comment was marked as duplicate.
This comment was marked as duplicate.
Sorry, something went wrong.
There was a problem hiding this comment.
I rebased this just to fix the commit messages and move the doc fixup commit into the one it was fixing. I did not resolve the merge conflict that has come up since this was contributed. @JasperDeSutter is there any chance you are still around and could have a look at this? This project is in a little better position to move on with contributions now (see #347 for background).
JasperDeSutter
force-pushed
the
argument-resolver
branch
from
4268ade
to
7c2d199
Compare
|
Great to see this project more alive again! I'll pick up my PRs that are still open, though it has been a while so it might take some time to get them all updated. |
JasperDeSutter
force-pushed
the
argument-resolver
branch
from
7c2d199
to
4f67e69
Compare
The main value add for a custom argument resolver is not needing to put arguments into a FluentArgs, which has no type safety. See the typesafe_messages example that demonstrates this use case.
The first commit optimizes FluentArg by not storing keys as Cows, but as regular &str instead. This reduces a small overhead in data size and arg lookup performance.