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

Use serde_json APIs instead relying on value enum #51

Conversation

macisamuele
Copy link
Contributor

The goal of this PR is to decouple (as much as possible) from serde_json.
This is mostly needed to simplify the integration of json-trait-rs (#30).

I'm publishing this for initial review as it will be the base of the work for testing json-trait-rs.

I'm very sorry for the size of the PR ... :(

@macisamuele macisamuele force-pushed the maci-use-serde_json-API-instead-relying-on-Value-enum branch from 582d365 to 5ecf3ae Compare May 17, 2020 13:48
@@ -1,8 +1,19 @@
use serde_json::Value;

fn are_f64_equal(left: f64, right: f64) -> bool {
(left - right).abs() < 3. * f64::EPSILON
Copy link
Owner

Choose a reason for hiding this comment

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

Why not comparison of left_num and right_num?

@Stranger6667
Copy link
Owner

I'm very sorry for the size of the PR ... :(

No probs :)

I see that it does some negative impact on performance (however it is small in absolute numbers), e.g. with some type benches it has >+100% time change. I understand that it might be a cost to support non-serde case, but is there any way to avoid this? Or what ways do we have to improve it in the future?

@macisamuele
Copy link
Contributor Author

I was noticing the performance hit, but overall absolute number were very low.

Still I'm not 100% sure that json-trait-ts integration is feasible and reasonable. So I would eventually suggest to not merge this yet until some further tests are done

@Stranger6667
Copy link
Owner

Yep, let's take a look at how it could work performance-wise in comparison with other approaches.
I opened drafts #53 and #54 for comparison (I'd be glad if you can take a look). Will try to clean them up so it could be measured better

Cheers

@macisamuele
Copy link
Contributor Author

@Stranger6667 I'm going to drop this for now as it does have a massive amount of merge conflicts as well as #86 might also simplify this effort as it would require a very localised diff and not on all the keywords.

@macisamuele macisamuele deleted the maci-use-serde_json-API-instead-relying-on-Value-enum branch May 26, 2020 17:31
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.

2 participants