Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unify multisig structs Member and VoterResponse #151

Closed
maurolacy opened this issue Dec 4, 2020 · 4 comments
Closed

Unify multisig structs Member and VoterResponse #151

maurolacy opened this issue Dec 4, 2020 · 4 comments
Assignees
Milestone

Comments

@maurolacy
Copy link
Contributor

maurolacy commented Dec 4, 2020

Currently we have not two but three similar structs in multisig code, Voter, Member and VoterResponse.

Unify them into a common struct (Voter sounds like a good name), even when it implies introducing an explicit dependency between fixed-multisig and flex-multisig.

@ethanfrey
Copy link
Member

Do we still want to do this? Is it done?

@maurolacy
Copy link
Contributor Author

maurolacy commented Aug 17, 2021

This is trivial to do, but not yet done. I'll see that it's closed.

@ethanfrey ethanfrey added this to the v0.9.0 milestone Aug 17, 2021
@maurolacy
Copy link
Contributor Author

maurolacy commented Aug 18, 2021

OK, what's happening with these structs is that one set is in the context of cw3 (multisig) and the other is in the context of cw4 (groups).

In particular:

  • cw3::VoterResponse is identical to cw4::MemberResponse.
  • cw3::VoterDetail is identical to cw4::Member.

Now, given that cw4 is a late / more recent spec, I don't think it makes sense to introduce a dependency between the older cw3 spec and the newer cw4 spec (That is, mapping the cw3 voters to cw4 members).

And, the other way around (mapping cw4 members to cw3 voters) doesn't make much sense: A voter will in general be a member (of something), but a member wouldn't necessarily be a voter.

So, I think the sanest and simplest thing to do, is closing this without any changes.

@ethanfrey
Copy link
Member

So, I think the sanest and simplest thing to do, is closing this without any changes.

Sounds good.
The most maintainable PR is the PR never write

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants