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
Currently, if we want to change the parameters or return values of the original function, we are using a very error-prone and meticulously written code:
This troubles rule authors and is highly prone to errors. We should consider providing APIs in the CallContext to allow rule authors to easily modify parameters or return values without needing to understand the "pointer to a pointer is the original value" magic. For example:
This patch significantly changes the form of the hook code; specifically, CallContext is no longer a struct but an interface. The reason for this change is that we might be instrumenting different methods within the same package, and we need to generate the get/setParam functions at compile time. The parameter types of different methods are different, so we need to dynamically generate different struct implementations for different methods.
The text was updated successfully, but these errors were encountered:
Currently, if we want to change the parameters or return values of the original function, we are using a very error-prone and meticulously written code:
opentelemetry-go-auto-instrumentation/pkg/rules/test/fmt_hook.go
Lines 19 to 22 in 61d3c18
This troubles rule authors and is highly prone to errors. We should consider providing APIs in the CallContext to allow rule authors to easily modify parameters or return values without needing to understand the "pointer to a pointer is the original value" magic. For example:
This patch significantly changes the form of the hook code; specifically,
CallContext
is no longer a struct but an interface. The reason for this change is that we might be instrumenting different methods within the same package, and we need to generate the get/setParam functions at compile time. The parameter types of different methods are different, so we need to dynamically generate different struct implementations for different methods.The text was updated successfully, but these errors were encountered: