8 releases (1 stable)

1.0.0 Dec 8, 2019
0.6.0 Aug 22, 2019
0.5.0 Aug 4, 2019
0.4.0 Jul 29, 2019
0.1.1 Jul 7, 2019

#1248 in Data structures


Used in r1

Custom license

7KB

R/O

Project

Features

This crate helps make stuff read-only.

Inconvenient builder pattern

An example with builder pattern:

  • You make new struct with all fields private.

  • For each field, you might want to add 2 functions:

    • set_x(&mut self, ...): to change the field's value.
    • get_x(&self, ...): to access the field's value.

That works fine if your struct has several private fields. But it will be inconvenient when you add more and more fields: for each field, there's a chance that you will need to add 2 more functions. The more public API, the more you will have to maintain.

ReadOnly

This struct can help shorten your code:

  • You can make any of your struct's fields public.
  • Then you can implement Default. This could help your users with what you think good default values should be. They can adjust those values if needed.
  • Your code can freely accepts your own struct, and converts it into a read-only version. Then you can wrap that version inside an Arc, and share it across threads without worrying about Arc::get_mut().
  • Even in case your struct has some mutable functions, the read-only version still does its job well: mutable functions are not accessible.

Notes

The author believes that this crate should be used in binary programs, not in library crates. ReadOnly itself is extremely simple to code. So it would help your users a lot if you try not to include this crate as a dependency in your own libraries.

But, it's your choice.

No runtime deps