-
Notifications
You must be signed in to change notification settings - Fork 17
-
Notifications
You must be signed in to change notification settings - Fork 17
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
Type Safety? #1
Comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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: