Skip to content

Type Safety? #1

@songgao

Description

@songgao

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:

func (f *Functions) AttachInt(name string, f func(int, int) int) error
func (f *Functions) AttachFloat(name string, f func(float64, float64) float64) error

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:

type Functions struct {
    functions map[string]*function
}
type function struct {
    funcInt  func(int, int) int
    funcSetInt bool
    funcFloat func(float64, float64) float64
    funcSetFloat bool
}

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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions