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

Tracking: Ideas for useful helper functions #56

Open
5 tasks
matheus23 opened this issue Sep 25, 2024 · 2 comments
Open
5 tasks

Tracking: Ideas for useful helper functions #56

matheus23 opened this issue Sep 25, 2024 · 2 comments

Comments

@matheus23
Copy link

I'll try keeping track of some useful helper functions to include in willow-rs.

  • Some form of Range::new_exact:

    impl Range<Path> {
      fn new_exact_path(path: Path) -> Self;
    }

    An alternative for this would be:

    trait Successor { // which is actually equivalent to `trait SubspaceId` at this point.
      fn successor(&self) -> Option<Self>;
    }
    
    impl<T: Successor> Range<T> {
      fn new_exact(value: T) -> Self;
    }
  • Helpers for creating Paths from arrays of bytes/strings:

    impl Path {
      fn from_bytes(&[&[u8]]) -> Self;
      fn from_strs(&[&str]) -> Self;
    }
  • Helpers for printing Paths. Perhaps just a nice Path: Debug instance that interprets the path segments as utf8, if possible, or otherwise escapes to hex or similar. Alternatively something like Path::to_string(&self) -> Option<String> that tries to format using / and utf8, but fails if the path would have to be escaped.

  • Easily converting an Area into a Range3d: Area::to_range3d(&self) -> Range3d. Alternatively: a From/Into instance.

  • Easily converting an Area into an AreaOfInterest: AreaOfInterest::new_area(area: Area) -> Self or similar

@sgwilym
Copy link
Contributor

sgwilym commented Sep 25, 2024

Thank you for these suggestions, I'm agreed on all counts. I like the Successor trait, I think the only drawback would be needing a newtype to implement it on u64 for timestamps.

@matheus23
Copy link
Author

matheus23 commented Sep 25, 2024

FWIW, I personally find it just easy enough to do a Range::new_closed, if it's a Range<u64>, so I'd be fine without a newtype. (although you're risking a panic in case of an overflow)

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

No branches or pull requests

2 participants