Design Principle: Allow (or not) functions as data in data model?

[echeran]

In the data model, are we okay with treating functions as first-class data, such that we can include functions as a part of the data model for MF input?

@zbraniecki 's presentation on the Fluent-based POC showed the use of references to functions that can be used for custom placeholder formatting. @mihnita 's previous presentation on the data model discussed the idea of custom formatters for placeholders by indicating where those formatting args could be stored, and this too might require function interfaces to be defined to enable user-defined custom formatters.

I'm in favor of saying that we can treat functions as data, and thus, include them as fields in our data model. One counter-argument to the idea would be that not all programming languages allow first-class functions.

My perspective is that, for our purposes, declaring the type of a function and declaring a function interface are equivalent (arg types and return type). Most languages these days have interfaces/traits or first-class fns, and even for the few that don't, they do not need those languages features to create an implementation compatible with the data model.

If we do define behavior as fn interfaces or first-class fns, then it might open up different ways of addressing problems or implementing details. As a hypothetical example, if we want to generalize the notion of a default selection of a message variant in a multi-select message when placeholder values are absent, instead of relying on the structure of the message variants or adding fields to the data model, we could represent the selection process as a function. There could be a spec for fn behavior and the rest could be left to implementation details.

[mihnita]

Some programming languages are more flexible than others.

In some if I have the function name I can easily invoke the function (JS). In some I have to "jump through hoops" using something like reflection (Java). And in others the name of the function is completely lost at runtime, I need to keep somewhere a map of names to pointers to functions (C)

At a high level of abstraction they are equivalent.
But if we want to implement something portable across languages then probably we need something that is more down to earth.

I think that if we want our data model to be serializable and portable then we need to use function names.
Different implementations can have function references / pointers / functors / etc, but those would be private members, implementation details.

[eemeli]

One limitation that I think we can and should make is that the set of functions that could be called must be defined ahead of time. As in, there should not be a way that parsing a message could add to or modify the functions that could be called from the message itself. Because that way lies Turing-completeness.

[eemeli]

I believe that this is somewhat out of date, and the topic is now best approached through our work on the function registry.

[aphillips]

Closing as stale