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
VIP: 770
Title: Denote Static Call per Method in Contract Interface Definition
Author: @fubuloubu
Type: Standard Track
Status: Draft
Created: 2018-04-09
Simple Summary
Current method of defining contract interfaces decides whether to static call all methods based on the usage of the modifiable/static keyword. Suggestion would make this per-method.
Current method assumes all methods are state modifiable if modifiable keyword is used when referring to a variable storing that contract's address. This means if you would like to safely interact with a contract that implements multiple methods, only some of which are state changing, you will need to define two variables to do so, or always call read-only methods with a regular CALL opcode.
Proposed method would make this per-method, as detailed in Specification.
Motivation
This increases utility of the contract interface mechanism, and increases transparency into which calls should be made statically, and which are allowed to modify state.
Update per VIP #748 would make this syntax mesh much nicer than it currently will.
Specification
Proposed syntax would be (using Basic ERC20 interface standard):
contractERC20Basic:
defbalanceOf(_owner: address) ->uint256: staticdeftotalSupply() ->uint256: staticdeftransfer(_to: address, _amt: uint256) ->bool: modifying# Other methods not implemented in interface are not callabletoken: ERC20Basic@constant@publicdeftokenBalance() ->uint256:
returnself.token.balanceOf(msg.sender)
@publicdefgiveMeTokens():
self.token.transfer(msg.sender, self.tokenBalance())
We could also change the contract keyword (which is a search/replace for class) into interface, which I think makes the purpose clearer for these external contract interface types.
Backwards Compatibility
Not backwards compatible, modifies syntax for interface definitions
Preamble
VIP: 770
Title: Denote Static Call per Method in Contract Interface Definition
Author: @fubuloubu
Type: Standard Track
Status: Draft
Created: 2018-04-09
Simple Summary
Current method of defining contract interfaces decides whether to static call all methods based on the usage of the
modifiable
/static
keyword. Suggestion would make this per-method.Abstract
Currently, to work with external contracts, one must supply a keyword denoting whether to make calls using
STATICCALL
opcode for ALL methods in a external contract variable, e.g.:https://github.com/ethereum/vyper/blob/22be6dbae5a767a2d5525deb7cc93c45860e1982/tests/parser/features/external_contracts/test_modifiable_external_contract_calls.py#L14-L18
Current method assumes all methods are state modifiable if
modifiable
keyword is used when referring to a variable storing that contract's address. This means if you would like to safely interact with a contract that implements multiple methods, only some of which are state changing, you will need to define two variables to do so, or always call read-only methods with a regularCALL
opcode.Proposed method would make this per-method, as detailed in Specification.
Motivation
This increases utility of the contract interface mechanism, and increases transparency into which calls should be made statically, and which are allowed to modify state.
Update per VIP #748 would make this syntax mesh much nicer than it currently will.
Specification
Proposed syntax would be (using Basic ERC20 interface standard):
We could also change the
contract
keyword (which is a search/replace forclass
) intointerface
, which I think makes the purpose clearer for these external contract interface types.Backwards Compatibility
Not backwards compatible, modifies syntax for interface definitions
Copyright
Copyright and related rights waived via CC0
The text was updated successfully, but these errors were encountered: