Consider adding relevant network object to RpcArgs

[NoTuxNoBux]

Version Number and Operating System(s):

Windows 10, Forge Network Alloy at da8e129 (develop).

Expected behavior:

Easy way to access relevant network object RPC was invoked on from RpcArgs (or RpcArgs.RPCInfo).

This is a fairly minor thing, since RPC handlers exist in the network object to begin with, grabbing networkObject inside the behavior object is fairly easy to do to work around this. The reason I'm asking is because during refactoring one may create different classes to handle specific RPCs, which then need to be passed not only the RpcArgs, but also the relevant NetworkObject. This results in a so-called data clump.

Actual behavior:

No way to easily access relevant network object RPC was invoked on from RpcArgs.

Steps to reproduce:

Create an RPC and a handler for it and observe that you cannot directly access the relevant network object from it.

[TheYellowArchitect]

The reason I'm asking is because during refactoring one may create different classes to handle specific RPCs, which then need to be passed not only the RpcArgs, but also the relevant NetworkObject. This results in a so-called data clump. Could you give an elaborate example? Because I cannot think of a use-case like this

Slightly off-topic: How big is a NetworkObject in byte size?

[NoTuxNoBux]

Could you give an elaborate example? Because I cannot think of a use-case like this

Sure! An example: I have a network object A supporting an RPC InitiateTransfer, and I create a class InitiateTransferRpcHandler (possibly implementing an IRpcHandler), with one method Handle(RpcArgs args). Nothing too fancy.

This separates the responsibility of handling the RPC from the network object itself, which is especially useful if it has many RPCs, keeps concerns separated, and allows minimizing injected dependencies in that class as well as for the network object (in case you use dependency injection, which I do).