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

Added DefaultBtreeMap and a set_default method. #10

Merged
merged 1 commit into from
Sep 10, 2020

Conversation

rljacobson
Copy link
Contributor

Added DefaultBtreeMap and a set_default method to both HashMap and DefaultBTreeMap.

@codecov-commenter
Copy link

codecov-commenter commented Aug 30, 2020

Codecov Report

Merging #10 into master will decrease coverage by 2.14%.
The diff coverage is 96.66%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master      #10      +/-   ##
==========================================
- Coverage   98.11%   95.97%   -2.15%     
==========================================
  Files           1        2       +1     
  Lines         159      273     +114     
==========================================
+ Hits          156      262     +106     
- Misses          3       11       +8     
Impacted Files Coverage Δ
src/btreemap.rs 96.26% <96.26%> (ø)
src/lib.rs 95.68% <100.00%> (-2.43%) ⬇️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 1e963db...baf5a95. Read the comment docs.

Copy link
Owner

@JelteF JelteF left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the work on this, but the way this PR is currently structered makes it very hard to review. Mainly because it does all kinds of refactors together with functionality changes. Can you change this PR to only do functionality changes?

Also, I just merged another PR with serde support. Please update this PR to include that as well.

src/btreemap.rs Outdated
@@ -0,0 +1,462 @@
/*!
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This commment should only be part of the main module. It just clutters the docs if it's on every page.

src/hashmap.rs Outdated
```
*/

use std::borrow::Borrow;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you leave the hashmap implementation in the src/lib.rs file? Now I have no clue what you changed here, because the git diff shows it all as new.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To clarify, you want only the hashmap in src/lib.rs? (Hashmap code wasn't changed, just copied+pasted.)

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah, I think I'll move it to a separate file after merging this like you did. But to be able to review the PR easily I'd like the changes to be minimal.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So with that the final changes should be:

  1. Add set_default to DefaultHashMap in src/lib.rs
  2. Add a src/btreemap.rs with your new btree code (with serde support copy pasted from defaulthashmap too).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yep, makes sense. In retrospect, I should have made two PRs: one for DefaultBTreeMap and one for set_default.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that would have been even better, but set_default is small enough that it's fine to have them together this time.

src/lib.rs Outdated
//! This is a problem for the first addition when there's no value for the key yet.
//! With this library you can specify when creating the map that the default value should be zero.
//!
/*!
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please leave the commenting style the same, so //! instead of /*!

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

facepalm Of course!

@rljacobson
Copy link
Contributor Author

@JelteF Since I am revisiting this PR, I might as well "do it right." There are a few more methods from BTreeMap that I would like to implement:

  • append()
  • range()
  • range_mut()
  • split_off()

The range() (range_mut()) method requires an additional Range (resp. RangeMut) structure. It is not clear what the semantics of range() should be. It could match that of get() in the sense that any key for which the map contains no value will produce (&key, &self.default). The alternative is that it matches the behavior of keys and skips over missing keys. The latter semantics makes more sense to me. A counter-argument is that then range() and range_mut() would give a different sequence—unless you have range_mut() work differently from get_mut().

While I am at it, should I implement the missing HashMap methods? They are:

  • iter_mut()
  • remove_entry()
  • with_capacity()
  • get_key_value()

I have excluded methods related to using a custom Hasher. To be blunt, I don't know anything about how custom Hashers, so it's easier to keep kicking that can down the road until someone wants it.

And since I am thinking about this, I would also like to implement an alternative semantics indicated by a new enum with variants InsertOnRead and InsertOnWrite. But this is an entirely separate PR. I'll open an issue to discuss it.

@JelteF
Copy link
Owner

JelteF commented Sep 7, 2020

I would say lets do those extra methods in an upcoming PR, since there might be more discussion points.

@JelteF
Copy link
Owner

JelteF commented Sep 7, 2020

You could create the PR already if you want though, but I don't think it should block merging this PR.

@rljacobson
Copy link
Contributor Author

Bit of a noob question, but how do I rebase my changes to the new upstream commit and keep the PR clean? Normally I would put my changes on a new branch, reset master to before my changes, git pull the upstream commits, and then rebase my new changes branch onto the updated master branch. But then to sync my github repo, wouldn't I have to git push --force? Then what happens to the PR?

@JelteF
Copy link
Owner

JelteF commented Sep 7, 2020 via email

@rljacobson
Copy link
Contributor Author

Thanks. I'll do that and squash my commits.

@JelteF
Copy link
Owner

JelteF commented Sep 10, 2020

Released this as 0.5.0

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

Successfully merging this pull request may close these issues.

3 participants