Use encoder/registry
to initialize encoder types
#2359
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
init()
should be avoided as much as possible, but we should make an exception for initializing encoder types.The problem with the old approach of registering types to encoder in the
blockchain
package is that, any other packages may need to explicitly callRegisterCoreTypesToEncoder()
if the blockchain object isn't created anywhere. This doesn't help with code readability. Moreover, in the tests, as the types aren't registered automatically, we either have to register types individually, callRegisterCoreTypesToEncoder()
or do something likeTestMain()
as shown instate_test.go
.The new approach creates a new package
encoder/registry
with aninit()
function that does the type registration. This package is blank imported in themain
package, so the types are initialized beforemain()
runs. For the test files,init_test.go
are created for each package, where all it does is blank import.Another alternative to this approach of test files is to create a new
testing
package (i.e.github.com/NethermindEth/juno/testing
) with the blank import and encapsulate the built-intesting
package. All tests should use this newtesting
package so that the types are initialized properly. I feel that this approach is slightly overengineering so I went with the former approach.Uber's go style guide also mentioned that we can make an exception for encoder type registry.