You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello mailgun! How's SFO doing? Super interesting project!
So I was thinking if it's feasible to add type safety check into this. Currently it parses the tokens, stores literals and function names, and then uses reflect to call the functions. What do you think about using different concrete function types (as opposed to unifying them with a single interface{})
So Functions would become a managed type (rather than map[string]interface{}) that has methods to attach different user-defined functions to it. To avoid reflection, this means multiple "attaching" methods need to be defined, for example:
When executing, rather than calling by reflect, it could first determine the actual function implementation to use based on literal types. Type conversion happens here: if a function is called with something like (int, float64), it would be automatically converted to (float64, float64) before calling the function. This removes the need to use reflection from both function and literal passing.
Internally in the Functions type, it would need to have references to different types, and keep track on which functions are attached and which are not. For example:
This way, you get the type safety check and reduce the reflection using.
However, it might be a bit too verbose for quick prototyping or whatever situations where people don't want to deal with all those stuff. So there could be an interface which is exactly like what's present now, and underlying handles all these automatically.
What do you think?
The text was updated successfully, but these errors were encountered:
Hello mailgun! How's SFO doing? Super interesting project!
So I was thinking if it's feasible to add type safety check into this. Currently it parses the tokens, stores literals and function names, and then uses reflect to call the functions. What do you think about using different concrete function types (as opposed to unifying them with a single interface{})
So
Functions
would become a managed type (rather than map[string]interface{}) that has methods to attach different user-defined functions to it. To avoid reflection, this means multiple "attaching" methods need to be defined, for example:When executing, rather than calling by reflect, it could first determine the actual function implementation to use based on literal types. Type conversion happens here: if a function is called with something like (int, float64), it would be automatically converted to (float64, float64) before calling the function. This removes the need to use reflection from both function and literal passing.
Internally in the Functions type, it would need to have references to different types, and keep track on which functions are attached and which are not. For example:
This way, you get the type safety check and reduce the reflection using.
However, it might be a bit too verbose for quick prototyping or whatever situations where people don't want to deal with all those stuff. So there could be an interface which is exactly like what's present now, and underlying handles all these automatically.
What do you think?
The text was updated successfully, but these errors were encountered: