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
We can currently compile a Roto script and then use get_function to get a function with known types from it. This is nice and works well within Rust, but it might not cover the use cases for Rotonda, because there we might need to pass types into a Roto script that are unknown at Rust compile time. This can for example happen in a case where we take the output of a Roto script and pipe it into another Roto script or store it in a database. In that first case, we need to know that the output type of the first script matches the input type of the second script. That's where schemas come in.
In list form, we need:
A type that represents some Roto type with a value that describes it's type. In other words: a dynamic Roto value.
In some way, this is equivalent to the TypeValue enum from the previous Roto version, but I'm envisioning this as a slice of data with type information instead. This ensures that we can also erase the type information and just work with slices once we have checked that the types are correct. It's also more flexible because it will support runtime types and other complex types.
Some way to retrieve schemas of types and functions from Roto, so we can inspect the types used in the script.
The way that we can implement this is by generating a *_dynamic version of each function that we expose. This version will take a pointer for each of its arguments and then call the non-dynamic version automatically.
The text was updated successfully, but these errors were encountered:
We can currently compile a Roto script and then use
get_function
to get a function with known types from it. This is nice and works well within Rust, but it might not cover the use cases for Rotonda, because there we might need to pass types into a Roto script that are unknown at Rust compile time. This can for example happen in a case where we take the output of a Roto script and pipe it into another Roto script or store it in a database. In that first case, we need to know that the output type of the first script matches the input type of the second script. That's where schemas come in.In list form, we need:
TypeValue
enum from the previous Roto version, but I'm envisioning this as a slice of data with type information instead. This ensures that we can also erase the type information and just work with slices once we have checked that the types are correct. It's also more flexible because it will support runtime types and other complex types.The way that we can implement this is by generating a
*_dynamic
version of each function that we expose. This version will take a pointer for each of its arguments and then call the non-dynamic version automatically.The text was updated successfully, but these errors were encountered: