-
Notifications
You must be signed in to change notification settings - Fork 45
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specifiy allowed or forbidden behavior of Functions #294
Comments
I had to do some work to account for nondeterministic/impure functions, so forbiding them will simplify things a bit. But aren’t there use cases which do require them? How would you write this, for example? (Different localizations may define different number of synonyms.) greeting = { RANDOM(3) ->
[1] Greetings, {$userName}!
[2] Hello, {$userName}!
*[3] Hi, {$userName}, and have a nice day!
} |
I'd prefer to see functions defined as being deterministic with no side effects - because of the principle of least power, and considerations for the different implementations I'm working on, several of which assume pure functions only :-) I can see the use case for functions like I can think of one work-around for implementing
The application would have to retrieve the So
|
Thank you, your solution looks nice (well, nicer than those I thought about). And if a message needs several random numbers (don’t know why), it can request a bigger number and call And… aside from |
They are seldom needed to localizers and aren't portable across implementations. See related discussion: projectfluent/fluent#294
I think we should make some statements around what Functions are allowed to do and not, as part of our resolver spec.
In particular, I think we should
The text was updated successfully, but these errors were encountered: