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

Remove TryFrom/Into conversion of HashMap, and implement into_hashmap() and from_hashmap() #254

Merged
merged 14 commits into from
Nov 23, 2021

Conversation

yutannihilation
Copy link
Contributor

@yutannihilation yutannihilation commented Aug 8, 2021

Close #230

  • <List>::from_hashmap()
  • <List>::into_hashmap()
  • <HashMap<>>::from_list()
  • <HashMap<>>::into_list()

@andy-thomason
Copy link
Contributor

Do you need some help with this?

@yutannihilation
Copy link
Contributor Author

@andy-thomason
Thanks, my problems are mainly

  1. I don't keep up with the recent progress of TryFrom conversions. I think I can make it eventually, but feel free to take this over.
  2. To implement the latter half of the goals of this pull request, <HashMap<String, T>>::{from_list, into_list}, I need to figure out the convention of the traits, which will be determined on Design document for Traits #306. So, I'm wondering if I should wait and create a separate pull request.

@yutannihilation yutannihilation changed the title Remove TryFrom/Into conversion of HashMap, and implement into_hashmap() and from_hashmap() Remove TryFrom/Into conversion of HashMap Oct 19, 2021
@yutannihilation yutannihilation changed the title Remove TryFrom/Into conversion of HashMap Remove TryFrom/Into conversion of HashMap, and implement into_hashmap() and from_hashmap() Oct 19, 2021
@yutannihilation
Copy link
Contributor Author

I think this is ready for review now. I removed many integrated tests related to List because this is no longer a conversion that happens between R session and Rust code, so I think unit tests are enough.

Copy link
Member

@clauswilke clauswilke left a comment

Choose a reason for hiding this comment

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

Looks good to me in principle. I have a few minor comments.

/// assert_eq!(names, vec!["a", "b"]);
/// }
/// ```
pub fn from_hashmap<K>(val: HashMap<K, Robj>) -> Result<Self>
Copy link
Member

Choose a reason for hiding this comment

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

Should this take a reference? Otherwise, maybe mention in line 66 that the HashMap is consumed?

Copy link
Member

Choose a reason for hiding this comment

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

Maybe I am missing something, but why not make it a TryFrom implementation?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@clauswilke
I think the result List should own Robjs in the HashMap, so HashMap should be consumed.

@Ilia-Kosenkov
Because the conversion is lossy. Please refer to #230 (comment) for the related discussions.

Copy link
Member

Choose a reason for hiding this comment

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

@yutannihilation That's fine. Then I'd say so explicitly in the docstring.

Copy link
Member

Choose a reason for hiding this comment

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

OK I see. If we do not have it (or have it planned), it may be useful to have trait for lossy conversions instead of multiplying from_name and to_name functions.


/// Convert a List into a HashMap, consuming the list.
///
/// - If there are some duplicated name of elements, only one of those will be preserved.
Copy link
Member

Choose a reason for hiding this comment

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

"names"

/// Convert a List into a HashMap, consuming the list.
///
/// - If there are some duplicated name of elements, only one of those will be preserved.
/// - If an element doesn't have the name, an empty string (i.e. `""`) will be the key.
Copy link
Member

Choose a reason for hiding this comment

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

"doesn't have a name, ... will be used as the key"

Also mention what happens when there are multiple elements without name?

expect_error(list_str_hash(20:30), "expected a list")
expect_error(list_str_hash(NA), "expected a list")
expect_error(list_str_hash(e), "expected a list")
# TODO
Copy link
Member

Choose a reason for hiding this comment

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

Can we add some tests here before merging, or is there a reason to defer?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This TODO doesn't mean we need to add some tests for list. As I commented above, I intentionally removed integrated tests because this is no longer what happens inside the [#extendr] macro, so I think unit tests are enough.

If this comment is confusing, I'll remove this.

expect_error(try_list_str_hash(20:30), "Expected List got Integer")
expect_error(try_list_str_hash(NA), "Expected List got Logical")
expect_error(try_list_str_hash(e), "Expected List got Environment")
# TODO
Copy link
Member

Choose a reason for hiding this comment

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

See above.

CHANGELOG.md Outdated
Comment on lines 31 to 32
- Remove `TryFrom` conversions between `Robj` and `HashMap` for consistency. Use explicit conversions by `List::into_hashmap()` and `List::from_hashmap()` instead.

Copy link
Member

Choose a reason for hiding this comment

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

I think changelog should be in past simple. I suggest to slightly rephrase it to
"Removed TryFrom conversions between Robj and HashMap for consistency. List::into_hashmap() and List::from_hashmap() should be used instead."

@yutannihilation
Copy link
Contributor Author

Thanks, I addressed the comments.

@yutannihilation
Copy link
Contributor Author

@andy-thomason
Can I merge this?

@andy-thomason andy-thomason merged commit f1ce194 into extendr:master Nov 23, 2021
@yutannihilation yutannihilation deleted the fix/issue-230-hashmap branch January 23, 2023 11:42
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.

Conversions to and from hashmap
4 participants