There are a number of methods that already accept/return parameters that have semantics of resource accounting (resource limits/usage amount, etc). The type of these parameters can not be changed because of compatibility reasons. This is why we have introduced additional rules that describe POA Public API policy regarding this issue.
In general, an additional method parameter of type
bigint is introduced. The name of that parameter partially coincide with original one with one exception that new parameter will have '64' prefix.
In case of input parameters, an introduced
bigint parameter is optional. So it is safe for the user to keep using specific methods in a usual way, transferring usual
int parameters. However, if it appears that user should transfer big number, he could use
bigint parameter and do not transfer
int parameter at all (or leave it 0 because
bigint parameter has higher priority).
POA Public API will always transfer both
bigint output parameters that refer the same value. If it appears that the actual value does not fit the
int representation, then the minimal negative or maximum positive integer would be returned in int-typed parameter (depending on actual value) and correct value will be returned in bigint-typed parameter. So it is relatively safe to keep reading
int output parameters but it is better to always use their
Please note that rules described in this section concern existent method parameters only. The new
bigint parameters will not have any
int analogs and will be named in a usual fashion (no '64' prefixes).