api: Consider dropping EDS importing in favour of EDS constructor #85
Labels
enhancement
New feature or request
Comments
Closed
This was referenced Jul 6, 2023
rootulp
added a commit
that referenced
this issue
Jul 7, 2023
Closes #231 This PR adds a new constructor called `NewExtendedDataSquare` that allows @celestia-node to explicitly set the `chunkSize` on an empty EDS. I choose to not drop the existing `ImportExtendedDataSquare` as proposed in #85 because that would be public API breaking. cc: @Wondertan @walldiss
0xchainlover
pushed a commit
to celestia-org/rsmt2d
that referenced
this issue
Aug 1, 2024
Closes celestiaorg/rsmt2d#231 This PR adds a new constructor called `NewExtendedDataSquare` that allows @celestia-node to explicitly set the `chunkSize` on an empty EDS. I choose to not drop the existing `ImportExtendedDataSquare` as proposed in celestiaorg/rsmt2d#85 because that would be public API breaking. cc: @Wondertan @walldiss
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, EDS can only be imported from a flattened data square slice and is updated in place, breaking encapsulation and allowing users to incorrectly change the underlying slice causing undefined behavior for the library if used incorrectly. Instead, we should provide a new constructor that allocates/manages the EDS independently and provide proper setters/getters(such as #83) to make the rsmt2d foolproof by hiding complexity and further allocation/performance optimizations behind the API.
The text was updated successfully, but these errors were encountered: