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

Introduce gstd-primitives crate #2944

Closed
breathx opened this issue Jul 13, 2023 · 1 comment · Fixed by #3919
Closed

Introduce gstd-primitives crate #2944

breathx opened this issue Jul 13, 2023 · 1 comment · Fixed by #3919
Assignees
Labels
C1-feature Feature request

Comments

@breathx
Copy link
Member

breathx commented Jul 13, 2023

Details: #2944 (comment)

@breathx
Copy link
Member Author

breathx commented Apr 26, 2024

Initial problem of copy-pasting such primitives now occurs in brand-new framework sails, where another ActorId should be implemented as defaults since all of the user-space copy-paste the methods as well: gcore, gstd, gtest, gsdk, gclient.

Motivation: implement crate gprimitives that will be used as the only source of the types for all user-space libraries. Same it is for core parts where ids from gear-core reused everywhere; merging them into one type as well feels excess atm, but may be considered in future in order to focus on existing problem.

Implementation details with different features that drives this public types:

  • no-features: nothing, similar to gcore impls with open inner structs, no allocation-related fns etc; consider debug-display prints bytes
  • std: similar to gstd impls with unaccessible underlying data, high-level interactions, constructors from strings like hex, bs58 etc; avoid inner mutability there as well as the accesses; debug-display prints hexes
  • mock: provide some tests-compatible utility like impl From<u64> and anything that could be useful;
  • serde: for gsdk and similar http-requesters; impl serdes ser/deserialise traits;
  • codec: (included by default from std): impl Encode/Decode/MaxEncodedSize etc
  • consider any additional features to be implemented

TODO: Once this issue is resolved, remove sails_rt::ActorId and similar types in favour of this crate @DennisInSky

TIP: While implementing I'd separate the types for modules. Even with code repetitions it will be much more readable to have them declared separately (some common things could be implemented using crates like derive_more, or impl internal-use declarative macros in special macros or utils module to reuse them in id/actor, id/message, id/reservation modules)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C1-feature Feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants