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

style: standardize protobuf type aliases #454

Open
Mirko-von-Leipzig opened this issue Aug 23, 2024 · 0 comments
Open

style: standardize protobuf type aliases #454

Mirko-von-Leipzig opened this issue Aug 23, 2024 · 0 comments
Labels
good first issue Good for newcomers
Milestone

Comments

@Mirko-von-Leipzig
Copy link
Contributor

Mirko-von-Leipzig commented Aug 23, 2024

We currently use a variety of styles to refer to and alias protobuf message types.

This comes up within the proto crate itself, where we have mappings from the domain type T and the generated protobuf type T. In particular when implementing conversions to and from these types.

In the long run we hope to refactor the proto crate to have less clutter, but until then we should at least be consistent in how we refer to these types.

A quick and dirty option is to go through all instances referring to the proto types and make them consistent e.g. have them look like proto::T so that a conversion function is

impl From<BlockHeader> for proto::BlockHeader {...}

Another more thorough option is to re-organize the proto crate so that all domain types are exported at the root level, and all protobuf messages are in a module e.g. raw.

This would be a breaking change though, but maybe its not so bad :)

See here for example.

@bobbinth bobbinth added this to the v0.6 milestone Aug 27, 2024
@bobbinth bobbinth added the good first issue Good for newcomers label Sep 2, 2024
@bobbinth bobbinth modified the milestones: v0.6, v0.7 Oct 27, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
Status: No status
Development

No branches or pull requests

2 participants