transparent proxy support

[jimscarver]

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.

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

contract proxy(one) { channel!(one) } |
contract proxy(one, two) { channel!(one, two) } |
contract proxy(one, two, three) { channel!(one, two, three) } |
...

Examples

Match can allow simplified control of proxy alternatives. e.g.

match tuple {
  (one,two) => { proxy!(one, two) }
  * => { proxy!(tuple...) } 
}

Comparison Examples

Counter-Examples

Design

Counter-Examples

Drawbacks

Alternatives

References

https://refactoring.guru/design-patterns/proxy

[jimscarver]

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.