Proxy channels are valuable to control access to a capability such as ont time capabilities, revocable capabilities, remote channels (#45), decorator patterns, etc. Currently when we do not know how many arguments might be sent to a proxy we must implement a contract for every possible number of arguments. Unless we limit the number of arguments in a send the proxy will fail if the channel receives a message with too many arguments.
The proposal is that arg... binds the name arg to a tuple and arg... in a send sends the arguments in the tuple.
contract proxy(tuple...) = {
channel!(tuple...)
}
Motivating Examples
Currently a simple rholang proxy is awkward and inefficient. It requires a contract for each of the possible number of arguments
Another use case: Transparent proxies for channels created in test programs could be used to trace sends and to channels and test assertions to help facilitate debugging.
Introduction/Motivation/Abstract
Proxy channels are valuable to control access to a capability such as ont time capabilities, revocable capabilities, remote channels (#45), decorator patterns, etc. Currently when we do not know how many arguments might be sent to a proxy we must implement a contract for every possible number of arguments. Unless we limit the number of arguments in a send the proxy will fail if the channel receives a message with too many arguments.
The proposal is that arg... binds the name arg to a tuple and arg... in a send sends the arguments in the tuple.
Motivating Examples
Currently a simple rholang proxy is awkward and inefficient. It requires a contract for each of the possible number of arguments
Examples
Match can allow simplified control of proxy alternatives. e.g.
Comparison Examples
Counter-Examples
Design
Counter-Examples
Drawbacks
Alternatives
References
https://refactoring.guru/design-patterns/proxy