Accessing ParametersSpec from a DefGen in a native function about starlark-rust

[ndmitchell]

The idea of the function is that it is currently opaque - you can invoke it, but there's no way to get the and give it arguments, but you can't inspect what arguments it requires or what its name is. To change that we'd need to:

• Make some of ParametersSpec transparent - currently all you can do is give it arguments. This would require careful design to expose the right information.
• Make the FunctionInvoker you get back from .invoke give you a ParametersSpec back. This one isn't so hard.

What's the reason for wanting to understand the function arguments passed to a native function?

[oakash]

I'm seeing if it is feasible to use starklark-rust to define "callback" methods to events.

For example, a developer would pass a method to a native Rust function in that's exposed to Starklark, which would get evaluated when a particular event happens at a later time:

def handle_message(title, body):
    if title == "error":
        native.send_email("[email protected]", body)

native.on_message(func=handle_message)

This program would get evaluated and a reference to the callbacks to on_message stored somewhere, for example in a database. When an event comes in, the program would get evaluated again in a different context, and handle_message evaluated with the incoming message.

I was toying with the idea of inspecting the parameters specified on the method to match the incoming event to parameter names to make it a bit easier to use.

There are various other ways this could be achieved. For instance by evaluating the program for each message and use the Context to determine which callbacks to trigger based on the incoming message. That's the approach I'll be trying out today.

[oakash]

As I sat down to look at this again today I realize I can get pretty far by introducing a level of indirection in starlark and use kwargs. I was bit too stuck in the Rust mindset and looking to solve it there.

Thanks for the library. I don't have a need to expose function details directly Rust integrators right now. Until that changes I'll go ahead and close this ticket.

[ndmitchell]

Glad you've figured out a way.

Note that you might want to update the code if you still have Context - the latest code has moved to use Evaluator as the name. As part of the preparation for a release (which we're planning tomorrow) we've renamed a bunch of names that hadn't been considered since the initial fork. Following our release tomorrow we expect things to be pretty stable.

There is also the function eval_function that might be useful for what you are doing - not sure if you've seen that or not.