-
Notifications
You must be signed in to change notification settings - Fork 394
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
Comparing primitive pointers #392
Comments
The thing is, there is no strict alignment between ECMAScript and Go, so whatever mapping mechanism is in place, someone is bound to be unhappy 😄 To me the current mapping is at least consistent, the pointer to a primitive is not a primitive so the strict equality operator does exactly what it is supposed to do, comparing pointers, e.g.: var i int
vm := New()
vm.Set("i", &i)
vm.Set("i1", &i)
res, err := vm.RunString("i === i1")
if err != nil {
t.Fatal(err)
}
if res.Export() != true {
t.Fatal(res)
} The converted value is a host object that behaves similarly to Changing As I hinted in #377, it's possible to implement your own version of Having said that, I'm open to suggestions on how to make |
I understand why goja functions this way, but using Number, String, and Boolean in JavaScript is generally a bad practice because they cannot be triple equaled. I've two ideas for the public API:
|
It only works for structs, what about map values or just standalone variables? |
We could do something like a field value mapper, in there we could have a method |
Goja will convert a go pointer of a primitive type to a JS object, and this prevents this value to be triple equaled in JavaScript. From my point of view this is counterintuitive because I'd expect that *uint16(nil) would be js(undefined or null) and a non nil pointer would be just the primitive value.
I could manually create the object via
vm.NewObject()
, but this would create boilerplate, which the https://github.com/dop251/goja#mapping-struct-field-and-method-names tries to prevent.This issue is kinda a duplicate of #377, but I felt like it doesn't really describe the problems with this behavior. Feel free to close the issue regardless, as this probably makes the internal implementation of all primitive types more complex.
Simple example of the behavior:
The text was updated successfully, but these errors were encountered: