Use constructor to construct action instead of assigning members after the fact.
#951
Conversation
greg7mdp
requested review from
linh2931,
spoonincode and
heifner
and removed request for
linh2931 and
spoonincode
| test.account = "wasmtest"_n; | ||
| test.name = account_name((uint64_t)index); | ||
| test.authorization = {{"wasmtest"_n, config::active_name}}; | ||
| action test({{"wasmtest"_n, config::active_name}}, "wasmtest"_n, account_name((uint64_t)index), {}); |
There was a problem hiding this comment.
I guess we found no way to regenerate these files properly? I think if anything should update the generator,
btw it sure looks like AntelopeIO/wasm-spec-tests@026fb4b found a way to regenerate.
There was a problem hiding this comment.
Updated the generator b158e5b.
| act.authorization = vector<permission_level>{{signer, config::active_name}}; | ||
| act.data = abi_ser.variant_to_binary(action_type_name, data, abi_serializer::create_yield_function( T::abi_serializer_max_time )); | ||
| action act(vector<permission_level>{{signer, config::active_name}}, "eosio.token"_n, name, | ||
| abi_ser.variant_to_binary(action_type_name, data, abi_serializer::create_yield_function( T::abi_serializer_max_time ))); | ||
|
|
There was a problem hiding this comment.
I feel the original way of initializing individual fields explicitly clearer and more readable. action is a data class and used most locally. It is probably appropriate to be a struct without const.
There was a problem hiding this comment.
I very much disagree. Because action has constructors, it implies that the object should be constructed using the provided constructors.
The direct member initialization forgoes any hope to ensure that objects are always constructed in a consistent fashion, and that some internal members (possibly dependent on the constructors parameters) are always initialized correctly. This is not the case for action, but I feel it is a better pattern to follow.
There was a problem hiding this comment.
@arhag do you have an opinion on whether it is worthwhile to merge this PR?
|
Note:start |
This is an experiment attempting to make two members of
action_baseconst.We likely do not want to merge the
constchange as it may cause other repo tests to fail (change in second commit 986562e). However this commit was removed in the current version of the PR.I propose that we merge the PR as it currently is. It does not change
action_base, but updates our code to constructactionusing the constructor, instead of declaring a default constructed object and assigning the members after the fact.There should be no functional difference, besides constructing
actionwith the constructor instead of individual member assignments.