-
Notifications
You must be signed in to change notification settings - Fork 60
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
Additional equality metric accommodating JS numeric semantics? #156
Comments
I very much understand the request, especially as JSON doesn't really have ints or floats, it just defines numbers. Structural equality is simple and more or less well-defined, but adding the JavaScript semantics of If we find reasonable semantics for it, sure, I wouldn't mind including it, but I wouldn't want to add something half-baked that only works in some cases. |
It's a fair question. I did aim to constrain the scope of things to (well-defined) numerics, for all the reasons you mentioned. I personally don't think the truly degenerate cases of JS equality should be propagated anywhere ( So, if the acceptable enhancement is "all of JS equality or nothing", I guess I'd say it's better to do nothing. 🤷 |
Yes, if the only part is numeric equality, then it is ok. Likewise, I'm not too keen in implementing the whole JavaScript equality semantics (though I'm slightly worried about the case of comparing |
The
equals
implementation developed in #71 and #73 is a straightforward structural equality, and does good work in that context.However, I occasionally find myself wishing there was an equality metric that accommodated JS-native semantics vis a vis numbers. The nit is that yojson always distinguishes between ints and floats, even if said floats have a zero fractional part, while JSON parsers in Javascript engines do not (e.g.
JSON.parse("5.0")
⇒5
). So, it's easy to produce yojson structures that are not equal in the strict structural sense as currently implemented inequals
, but which are equal per JS semantics.As things stand, the only generalized workaround is a rewrite of the yojson trees being compared with
equal
to truncate any zero-fractional`Float
to its corresponding`Int
.Any interest in adding this?
The text was updated successfully, but these errors were encountered: