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
{{ message }}
This repository has been archived by the owner on Aug 15, 2022. It is now read-only.
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.
The text was updated successfully, but these errors were encountered:
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?
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).
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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
(orRpcArgs.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 theRpcArgs
, but also the relevantNetworkObject
. 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.
The text was updated successfully, but these errors were encountered: