Merge view and void entrypoints
A1 TZIP specifies two types of entrypoints whose purpose is to access some data from contract state:
- View entrypoints are defined as
view a r = (a, contract r)
. They allow other contracts to get some data from the current contract. You have to passcontract r
value which serves as a callback. It means that you have to originate a contract with parameter typer
or an entrypoint of typer
in order to use it. - Void entrypoints are defined as
void a b = (a, lambda b b)
. They can be used off-chain to get some data from the contract. They do not require submitting anything to the Tezos network.
If we consider contract storage to be implementation detail, then one should access its data only using entrypoints. Sometimes we want to have a getter that can be used by other contracts (to get some data from this one) and be used off-chain to get some data easily.
I propose to add another type of "getter" entrypoint: one which combines view and void entrypoints. It should have two parameters (a
and r
) and be defined as (a, option (contract r)
. The idea is that if the second item is Some contract
, we treat it as a view entrypoint and if it is None
, we treat it as a void entrypoint and use FAILWITH
. The name of this entrypoint type is questionable, I will call it getter
in the rest of this issue, but I am not sure it's the best naming.
It's questionable what to do with view and void entrypoints: do we want to always use getter
or there are usecases for void
and view
?
-
void
entrypoints are useful when you do not want to expose some data to any other contract. I think we should definitely keep them. -
view
entrypoints make it harder to get some data from outside. But it is still possible. I think the only advantage ofview
compared togetter
is that it is a bit cheaper, but the difference should be quite negligible.
That being said, I propose to deprecate view
and not deprecate void
.
Also A1 says the following about void entrypoints:
They are included in the contract interface primarily to provide enable trust-less computation on the contract's storage. That is, the presence of the entrypoint on-chain implies that all parties can have certainty that anyone who calls a
void
with identical arguments will compute the same result.
But I think it doesn't describe the main reason why they are useful: to be able to access contract data without knowing anything about its storage.