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|
#1371 in Data structures
43 downloads per month
Used in r1
- Repository: https://bitbucket.org/haibison/ro
- License: Nice License 1.0.0 (see LICENSE file at root directory of
- This project follows Semantic Versioning 2.0.0
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.
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
- Even in case your struct has some mutable functions, the read-only version still does its job well: mutable functions are not accessible.
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.