These traits represent abstract store objects than can store arbitrary data
blocks with store-generated indexes.
A NullStore implementation is provided which acts an always-empty StoreView.
Details
Details
- Reviewers
jsgf durham - Group Reviewers
Restricted Project - Commits
- rFBHGX7111992684f6: treedirstate: add Store and StoreView traits
Diff Detail
Diff Detail
- Repository
- rFBHGX Facebook Mercurial Extensions
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
Event Timeline
| rust/treedirstate/src/store.rs | ||
|---|---|---|
| 8 | Also usize isn't the right type to use for non-memory things. If the store is >4G then usize wouldn't be large enough on a 32 bit machine. | |
| rust/treedirstate/src/lib.rs | ||
|---|---|---|
| 18–23 | They're used in vecmap. I couldn't really think of good properties to quickcheck for these traits. | |
| rust/treedirstate/src/store.rs | ||
| 8 | I've changed BlockId to be pub struct BlockId(u64). I'm not sure if this is the right approach, though, as it means I need to use id.0 to pull out the number (e.g. to pass it to python code, or to write it out). Let me know what you think in the revised version. | |
| 20–24 | Yes, the blocks of data in the store are immutable once written. I'll highlight this in the comments. | |
| rust/treedirstate/src/errors.rs | ||
|---|---|---|
| 12 | Is there any convention in rust for explaining what macro's do? For instance, if I have worked in rust, but never seen error_chain before, do I need to go read the error_chain documentation in order to understand this file? Or should we have comments that describe what these things are doing? Seems like this type of problem will only grow as we depend on more and more macros. | |
| rust/treedirstate/src/store.rs | ||
| 12 | Assumed to be thread safe? Or no? Probably something we want to be explicit about if we're planning for a future where these things run in a daemon. | |
| 14 | Do we have line length lint rules for rust yet? | |
| rust/treedirstate/src/errors.rs | ||
|---|---|---|
| 12 | There is a way to expand macros. Although sometimes it's not human-readable. I think we won't need too many external macros. error_chain! and quickcheck! might be the only worthwhile ones for now. | |
| rust/treedirstate/src/store.rs | ||
| 12 | Structs using thread-unsafe primitives won't compile when being passed across thread boundary. | |
| 14 | rustfmt uses 100 characters by default. | |
| 56 | Maybe Boxed<[u8]> is better than Vec<u8> here to indicate the content is immutable. | |
| rust/treedirstate/src/store.rs | ||
|---|---|---|
| 56 | It's for test code only, so I'm ok with it being mutable (a future test may want to do some underhanded mutations). | |
| rust/treedirstate/src/store.rs | ||
|---|---|---|
| 8 | I think id.0 is OK, but you could perhaps implement From and/or Deref to pretty it up. | |
Is there any convention in rust for explaining what macro's do? For instance, if I have worked in rust, but never seen error_chain before, do I need to go read the error_chain documentation in order to understand this file? Or should we have comments that describe what these things are doing?
Seems like this type of problem will only grow as we depend on more and more macros.