Consider not importing default payload implementations for production applications #91
Labels
enhancement
Improving existing functionality
I3
Minimal impact
S3
Minimally significant
U4
Nothing urgent
Milestone
Comments
roman-khimov
added
enhancement
AnnaShaleva
added a commit
that referenced
this issue
Feb 13, 2024
A part of #2. Use generics instead of util.Uint160 and util.Uint256 types for DBFT and related components. Keep util.Uint160 and util.Uint256 only for specific DBFT implementation in testing code. The following regressions/behaviour changes were made to properly apply generics: 1. `dbft.Option` alias is removed since type parameters can't be defined on aliases (generic type aliases are prohibited). Ref. golang/go#46477. 2. Default dBFT configuration is reduced: all payload-specific defaults are removed, as described in #91. It is done because default dBFT configuration should not depend on any implementation-specific hash type. 3. DBFT configuration validation check is extended wrt point 2. 4. The check if generic `dbft.DBFT` type implements generic `dbft.Service` interface is removed since such check should be performed on particular (non-generic) DBFT implementation. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Feb 13, 2024
A part of #2. Use generics instead of util.Uint160 and util.Uint256 types for DBFT and related components. Keep util.Uint160 and util.Uint256 only for specific DBFT implementation in testing code. The following regressions/behaviour changes were made to properly apply generics: 1. `dbft.Option` alias is removed since type parameters can't be defined on aliases (generic type aliases are prohibited). Ref. golang/go#46477. 2. Default dBFT configuration is reduced: all payload-specific defaults are removed, as described in #91. It is done because default dBFT configuration should not depend on any implementation-specific hash type. 3. DBFT configuration validation check is extended wrt point 2. 4. The check if generic `dbft.DBFT` type implements generic `dbft.Service` interface is removed since such check should be performed on particular (non-generic) DBFT implementation. 5. `dbft.Service` interface is removed since it's unused. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Feb 13, 2024
A part of #2. Use generics instead of util.Uint160 and util.Uint256 types for DBFT and related components. Keep util.Uint160 and util.Uint256 only for specific DBFT implementation in testing code. The following regressions/behaviour changes were made to properly apply generics: 1. `dbft.Option` alias is removed since type parameters can't be defined on aliases (generic type aliases are prohibited). Ref. golang/go#46477. 2. Default dBFT configuration is reduced: all payload-specific defaults are removed, as described in #91. It is done because default dBFT configuration should not depend on any implementation-specific hash type. 3. DBFT configuration validation check is extended wrt point 2. 4. The check if generic `dbft.DBFT` type implements generic `dbft.Service` interface is removed since such check should be performed on particular (non-generic) DBFT implementation. Signed-off-by: Anna Shaleva <[email protected]>
AnnaShaleva
added a commit
that referenced
this issue
Feb 13, 2024
A part of #2. Use generics instead of util.Uint160 and util.Uint256 types for DBFT and related components. Keep util.Uint160 and util.Uint256 only for specific DBFT implementation in testing code. The following regressions/behaviour changes were made to properly apply generics: 1. `dbft.Option` alias is removed since type parameters can't be defined on aliases (generic type aliases are prohibited). Ref. golang/go#46477. 2. Default dBFT configuration is reduced: all payload-specific defaults are removed, as described in #91. It is done because default dBFT configuration should not depend on any implementation-specific hash type. 3. DBFT configuration validation check is extended wrt point 2. 4. The check if generic `dbft.DBFT` type implements generic `dbft.Service` interface is removed since such check should be performed on particular (non-generic) DBFT implementation. Signed-off-by: Anna Shaleva <[email protected]>
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Is your feature request related to a problem? Please describe.
I'm always frustrated when we import/build code we don't need. We have payloads/block implementations that are imported by default, but no real application uses them. They're useful for tests, they can be provided for edge cases, but they're not needed to be present in production builds.
Describe the solution you'd like
Drop defaults for
New*payload callbacks. They still can be used viapayload.*methods, we can even add some method to provide the default set of options for all of them, but we can avoid importing them in NeoGo or Bane.Describe alternatives you've considered
Keep this code in our builds. Nothing critical with this, btw.
Additional context
#89
#90
The text was updated successfully, but these errors were encountered: