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

refactor!: create math go sub module #11788

Merged
merged 27 commits into from
Apr 28, 2022
Merged

refactor!: create math go sub module #11788

merged 27 commits into from
Apr 28, 2022

Conversation

alexanderbez
Copy link
Contributor

@alexanderbez alexanderbez commented Apr 26, 2022

Description

Closes: #11784

  • Create math go sub-module
  • Move Int, and Uint types to math
  • Add aliases to types/math.go
  • Removed Int#ToDec (API breaking)

A beta release/tag of math will be made along with the replace directive being removed once this PR is merged.


Author Checklist

All items are required. Please add a note to the item if the item is not applicable and
please add links to any relevant follow up issues.

I have...

  • included the correct type prefix in the PR title
  • added ! to the type prefix if API or client breaking change
  • targeted the correct branch (see PR Targeting)
  • provided a link to the relevant issue or specification
  • followed the guidelines for building modules
  • included the necessary unit and integration tests
  • added a changelog entry to CHANGELOG.md
  • included comments for documenting Go code
  • updated the relevant documentation or specification
  • reviewed "Files changed" and left comments if necessary
  • confirmed all CI checks have passed

Reviewers Checklist

All items are required. Please add a note if the item is not applicable and please add
your handle next to the items reviewed if you only reviewed selected items.

I have...

  • confirmed the correct type prefix in the PR title
  • confirmed ! in the type prefix if API or client breaking change
  • confirmed all author checklist items have been addressed
  • reviewed state machine logic
  • reviewed API design and naming
  • reviewed documentation is accurate
  • reviewed tests and test coverage
  • manually tested (if applicable)

@alexanderbez
Copy link
Contributor Author

alexanderbez commented Apr 26, 2022

@aaronc we need to duplicate proto.go which defines the CustomProtobufType interface, which is easy to handle as we can duplicate it. However, the following causes another issue:

// ToDec converts Int to Dec
func (i Int) ToDec() Dec {
	return NewDecFromInt(i)
}

Should we:

  1. include Dec as part of math too OR
  2. create ToDec(i Int) in types (i.e. w/o the receiver -- this is a breaking API change)?

(1) allows use to avoid copying proto.go and is cleaner, but I don't know if this is what you intended in the original issue.

Copy link
Member

@tac0turtle tac0turtle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we alias the math package from types for a release and mark as deprecated, similar to errors

types/math.go Outdated Show resolved Hide resolved
@alexanderbez
Copy link
Contributor Author

should we alias the math package from types for a release and mark as deprecated, similar to errors

Yes :)

@aaronc
Copy link
Member

aaronc commented Apr 27, 2022

should we alias the math package from types for a release and mark as deprecated, similar to errors

I chatted with @alexanderbez about this a bit, but the idea is to keep the gogo proto and amino serialization in types.Int and math.Int will only include serialization logic for cosmos/cosmos-proto#2 (if needed). So likely types.Int will need to be a wrapper of math.Int with those additional serialization methods

@aaronc
Copy link
Member

aaronc commented Apr 27, 2022

@aaronc we need to duplicate proto.go which defines the CustomProtobufType interface, which is easy to handle as we can duplicate it. However, the following causes another issue:

// ToDec converts Int to Dec
func (i Int) ToDec() Dec {
	return NewDecFromInt(i)
}

Should we:

  1. include Dec as part of math too OR
  2. create ToDec(i Int) in types (i.e. w/o the receiver -- this is a breaking API change)?

(1) allows use to avoid copying proto.go and is cleaner, but I don't know if this is what you intended in the original issue.

What I'd propose for ToDec() is the same as what I'm proposing for all the marshaling logic/CustomProtoType - we leave those methods in types.Int for now but on a wrapper.

So in types/int.go we'd have:

type Int math.Int

func (i Int) ToDec() Dec {
  return NewDecFromInt(i)
}

I'd prefer to avoid API breakage in types/ but it's okay to have a slightly different API in math (because it's effectively a new package)

Copy link
Member

@aaronc aaronc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I'd propose is (for now at least) to leave all of this stuff in types/int.go on the types.Int wrapper type:

cosmos-sdk/types/int.go

Lines 335 to 434 in 019444a

func (i Int) MarshalJSON() ([]byte, error) {
if i.i == nil { // Necessary since default Uint initialization has i.i as nil
i.i = new(big.Int)
}
return marshalJSON(i.i)
}
// UnmarshalJSON defines custom decoding scheme
func (i *Int) UnmarshalJSON(bz []byte) error {
if i.i == nil { // Necessary since default Int initialization has i.i as nil
i.i = new(big.Int)
}
return unmarshalJSON(i.i, bz)
}
// MarshalJSON for custom encoding scheme
// Must be encoded as a string for JSON precision
func marshalJSON(i encoding.TextMarshaler) ([]byte, error) {
text, err := i.MarshalText()
if err != nil {
return nil, err
}
return json.Marshal(string(text))
}
// UnmarshalJSON for custom decoding scheme
// Must be encoded as a string for JSON precision
func unmarshalJSON(i *big.Int, bz []byte) error {
var text string
if err := json.Unmarshal(bz, &text); err != nil {
return err
}
return unmarshalText(i, text)
}
// MarshalYAML returns the YAML representation.
func (i Int) MarshalYAML() (interface{}, error) {
return i.String(), nil
}
// Marshal implements the gogo proto custom type interface.
func (i Int) Marshal() ([]byte, error) {
if i.i == nil {
i.i = new(big.Int)
}
return i.i.MarshalText()
}
// MarshalTo implements the gogo proto custom type interface.
func (i *Int) MarshalTo(data []byte) (n int, err error) {
if i.i == nil {
i.i = new(big.Int)
}
if i.i.BitLen() == 0 { // The value 0
copy(data, []byte{0x30})
return 1, nil
}
bz, err := i.Marshal()
if err != nil {
return 0, err
}
copy(data, bz)
return len(bz), nil
}
// Unmarshal implements the gogo proto custom type interface.
func (i *Int) Unmarshal(data []byte) error {
if len(data) == 0 {
i = nil
return nil
}
if i.i == nil {
i.i = new(big.Int)
}
if err := i.i.UnmarshalText(data); err != nil {
return err
}
if i.i.BitLen() > maxBitLen {
return fmt.Errorf("integer out of range; got: %d, max: %d", i.i.BitLen(), maxBitLen)
}
return nil
}
// Size implements the gogo proto custom type interface.
func (i *Int) Size() int {
bz, _ := i.Marshal()
return len(bz)
}
// Override Amino binary serialization by proxying to protobuf.
func (i Int) MarshalAmino() ([]byte, error) { return i.Marshal() }
func (i *Int) UnmarshalAmino(bz []byte) error { return i.Unmarshal(bz) }

To avoid carrying all the gogo/amino baggage

math/proto.go Show resolved Hide resolved
math/uint.go Show resolved Hide resolved
math/int.go Show resolved Hide resolved
@github-actions github-actions bot added the C:x/distribution distribution module related label Apr 27, 2022
@alexanderbez alexanderbez changed the title refactor: create math go sub module refactor!: create math go sub module Apr 28, 2022
@alexanderbez alexanderbez marked this pull request as ready for review April 28, 2022 13:00
Copy link
Member

@aaronc aaronc left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why did you decide to not create an Int wrapper type with the Dec method defined?

Otherwise LGTM

@alexanderbez
Copy link
Contributor Author

Why did you decide to not create an Int wrapper type with the Dec method defined?

Yes, correct. That one API was just not worth it -- a caller can and should just call NewDecFromInt.

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

Successfully merging this pull request may close these issues.

Migrate sdk.Int to math go module
4 participants