rchain / rchip-proposals

Where RChain improvement proposals can be submitted
Apache License 2.0
8 stars 5 forks source link

transparent proxy support #50

Open jimscarver opened 2 years ago

jimscarver commented 2 years ago

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 commented 2 years ago

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.