-
-
Notifications
You must be signed in to change notification settings - Fork 34
Data & Execution Model Differences
A comparison of the data and execution models suggested and required by the Elango-Mihai (EM) and Eemeli-Zibi (EZ) proposals.
EM: Limited by design. The longest structural path that a message may contain is: SelectorMessage -> messages[] -> SimpleMessage -> parts[] -> Placeholder -> formatter_name[] -> string.
EZ: Unlimited in theory, as e.g. a FunctionReference may contain another FunctionReference as one of its arguments.
One message indicating that some of its content should be read from another message.
EM: No direct built-in support. Allows for the definition of a message reference resolver as a custom formatting function. Availability of a message in general not possible to determine without execution.
EZ: Fully supported, including dynamic message references and variable scope overrides. General availability of a message easy to determine statically and ensure at the message resources level, at least for enumerable resources.
Using runtime values to influence message resolution.
EM: Basic built-in support with { name: string } placeholders. Allows for the definition of a variable resolver as a custom formatting function, for e.g. use in placeholder options or to allow for fetching values from within objects.
EZ: Fully supported, including dynamic variable references.
When implementing a formatting function, what values/arguments does it need to have access to?
EM:
-
value: unknown– The singular value being formatted -
options: Record<string, unknown>– A mutable map of options, originally the<string, string>map of options included in the placeholder, but possibly modified by earlier formatting function calls -
locale: string– The current locale -
getMessage(path: string[]): Message– A resolver for messages -
getRuntimeValue(name: string): unknown– A resolver for runtime parameters/arguments
EZ:
-
args: unknown[]– The value or values being formatted, known only at runtime -
options: Record<string, string | number | boolean>– An immutable map of options, known at build time -
locale: string– The current locale
How much trust must be placed on formatting functions?
EM: High. They must have access to everything that might be required to do any message formatting, including all runtime values. Spec extensions (e.g. as drafted here) may require parsing user input as executable code.
EZ: Low. Only the explicit arguments are accessible. All external data access must be via arguments, mediated by data model resolvers.
How easy or difficult is it to determine the expected types and validity of a message structure and its formatting arguments.
EM: Possible to some extent, but challenging. As anything other than plain text is represented by a placeholder, static analysis effectively depends on being able to determine the return values of formatting functions, which in turn may depend on all possible messages and runtime values. Availability of message dependencies is impossible to guarantee without execution.
EZ: Relatively straightforward. As message and variable references are built-in parts of the data model, their validity and requirements can be determined directly. This includes dynamic references. For the same reason, the scope of required message resources can be determined at build time.