yarpcDispatcherFn and yarpcStarterFn in modules/rpc should be public about fx HOT 4 CLOSED

Do you have a use case for the type? I realize it's a bit awkward, but this only exists so we have a hook to register uber-datacenter-internal dispatcher logic, which our users should never know about / care about / see

from fx.

I don't have one, but I still feel that they should be public. If we have use cases inside our datacenter, this sounds sufficient proof that it could be used by other developers too. The function has already been public, and hiding input parameter type cannot avoid people using it.

For "our users should never know about / care about / see", I totally agree and this gonna be a general pattern. I could foresee that all modules would need uber-specific logic at least for metrics and tracing. If we continue with this approach, it means that all module packages would have a global controller and a public function to register it. I think this may overuse global structs, and building customized dispatcher while ModuleCreateFunc is more native.

I don't have a good solution though. Maybe we need an internal version which includes uber-specific logic as default. :(

from fx.

I think Aiden meant why we need Register functions :)

As per function types, it doesn't really matter:
https://golang.org/ref/spec#Type_identity

Two function types are identical if they have the same number of parameters and result values, corresponding parameter and result types are identical, and either both functions are variadic or neither is. Parameter and result names are not required to match.

So yeah, for consistency we should make them public

from fx.

#247

from fx.