feat: add support for proposal types #2
Conversation
Signed-off-by: 0xRaccoon <[email protected]>
0xRaccoon
requested review from
eenti,
skeletor-spaceman,
0xParticle and
0xr3x
| @@ -32,6 +39,7 @@ abstract contract WonderGovernor is Context, ERC165, EIP712, Nonces, IGovernor, | |||
| keccak256('ExtendedBallot(uint256 proposalId,uint8 support,address voter,uint256 nonce,string reason,bytes params)'); | |||
|
|
|||
| struct ProposalCore { | |||
| uint8 proposalType; | |||
There was a problem hiding this comment.
beauty <3
is there any difference between placing this first or last?
There was a problem hiding this comment.
Good question; since there is no other uint8 data in the struct, I guess that the members' order won't significantly impact packing efficiency. We should put it in the best logical order for the best readability. What do you think will be a more readable placing proposalType before or after the proposer?
There was a problem hiding this comment.
tbh I have no idea. Is there a standard for this? it could be a question for the web3-devs channel
| */ | ||
| function getVotesWithParams( | ||
| address account, | ||
| uint8 proposalType, |
There was a problem hiding this comment.
is proposalType necessary to get the votes?
There was a problem hiding this comment.
Yes. This one, in its implementation, should query the token to get the votes by proposalType, which data will be in the Votes contract in the
mapping(address delegatee => mapping(uint8 proposalType => Checkpoints.Trace208)) private _delegateCheckpoints; member
Signed-off-by: 0xRaccoon <[email protected]>
Signed-off-by: 0xRaccoon <[email protected]>
Signed-off-by: 0xRaccoon <[email protected]>
Tech spec